401 Требуется авторизация на Apache 2.2, когда скручивание приводит к ошибке 500 лака
[centos@staging03 ~]$ sudo netstat -plnt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:80 0.0.0.0:* LISTEN 3600/httpd
tcp 0 0 127.0.0.2:80 0.0.0.0:* LISTEN 1574/varnishd
tcp 0 0 172.31.22.60:80 0.0.0.0:* LISTEN 1539/nginx
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1251/sshd
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1501/master
tcp 0 0 127.0.0.1:443 0.0.0.0:* LISTEN 3600/httpd
tcp 0 0 127.0.0.1:6082 0.0.0.0:* LISTEN 1573/varnishd
tcp 0 0 127.0.0.1:9000 0.0.0.0:* LISTEN 3468/php-fpm
tcp 0 0 127.0.0.1:11211 0.0.0.0:* LISTEN 1229/memcached
tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN 1061/redis-server 1
tcp 0 0 :::22 :::* LISTEN 1251/sshd
tcp 0 0 :::3306 :::* LISTEN 1383/mysqld
Я проверил, в чем проблема с моим сервером, и когда я это сделал,:
curl 127.0.0.1:80
я получил:
401 Требуется авторизацияТребуется авторизация
Этот сервер не смог проверить, что вы имеют право доступа к документу просил. Либо вы неправильно указали учетные данные (, например, неверный пароль)или ваш браузер не понимает, как предоставить требуемые учетные данные.
Apache/2.2.15 (CentOS )Сервер на 127.0.0.1, порт 80
На другом сервере, где все работает, я получаю пустой ответ. Поэтому я думаю, что именно поэтому я получаю ошибку 500 лака от Apache.
В журнале Apache я ничего не получил, когда закручивался, но до этого я получил:
[Wed Oct 27 17:02:25 2021] [notice] caught SIGTERM, shutting down
[Wed Oct 27 17:02:25 2021] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Wed Oct 27 17:02:25 2021] [notice] Digest: generating secret for digest authentication...
[Wed Oct 27 17:02:25 2021] [notice] Digest: done
[Wed Oct 27 17:02:25 2021] [notice] FastCGI: process manager initialized (pid 3602)
[Wed Oct 27 17:02:25 2021] [notice] Apache/2.2.15 (Unix) DAV/2 mod_fastcgi/2.4.6 configured -- resuming normal operations
Таким образом, кажется, что FastCGI настроен правильно, и проблема, которую я получаю от Apache, является проблемой аутентификации, как ни странно. Есть ли что-нибудь еще, что я могу сделать, чтобы определить, в чем проблема?
Varnish выдает следующее:
12 TxHeader b X-Varnish: 1537309960
12 RxProtocol b HTTP/1.1
12 RxStatus b 500
12 RxResponse b Internal Server Error
12 RxHeader b Date: Wed, 27 Oct 2021 21:14:18 GMT
12 RxHeader b Server: Apache/2.2.15 (CentOS)
12 RxHeader b Expires: Wed, 11 Jan 1984 05:00:00 GMT
12 RxHeader b Cache-Control: no-cache, must-revalidate, max-age=0
Однако у меня нет возможности проверить, что такое 500 Internal Server Error, потому что журналы ошибок для php кажутся пустыми.
TODO Apache
- Увеличить уровень журнала в Apache
- Проверить разницу между HTTP-вызовом статического файла в Apache и вызовом PHP
- Отслеживать журнал ошибок Apache с повышенной детализацией
цель состоит в том, чтобы получить HTTP 200 из Apache, запустив curl http://127.0.0.1либо на домашней странице, либо в каком-либо статическом файле.
TODO Varnish
- Обновите Varnish до поддерживаемой и поддерживаемой версии
- Добавьте внутренний зонд в свой VCL
- Отслеживайте работоспособность серверной части через VSL
На основе предоставленных вами выходных данных VSL я вижу, что вы Используете древнюю версию Varnish. См. https://www.varnish-software.com/developers/tutorials/installing-varnish-centos/, чтобы узнать, как установить Varnish 6.0 LTS на CentOS.
Мало того, что у вас есть безопасная версия Varnish, ваши инструменты VSL, (такие varnishlog), также намного лучше, чем в той версии, которую вы используете.
Вот пример бэкенда, который имеет проверку работоспособности.:
backend default {
.host = "127.0.0.1";
.port = "8080";
.probe = {
.url = "/";
.timeout = 2s;
.interval = 5s;
.window = 10;
.threshold = 5;
}
}
Это позволит вам постоянно следить за работоспособностью вашего бэкенда. Вы можете сделать это с помощью следующей команды :
sudo varnishlog -g raw -i Backend_health
. Вывод поможет вам понять, как ведет себя серверная часть и какой код состояния HTTP он возвращает в Varnish.
Объедините это с поиском получения кода состояния HTTP 200 от Apache, и вы очень близко приблизитесь к окончательному решению.