☰

Нужно полезное сообщение об ошибке от mod_proxy_fcgi

tag-icon • tag-icon apache-2.2 php apache-2.4
Нужно полезное сообщение об ошибке от mod_proxy_fcgi

Когда запрашивается несуществующий PHP-скрипт, mod_proxy_fcgi выдает довольно бесполезное сообщение об ошибке, по сути просто говорящее:

[proxy_fcgi:error] .... AH01071: Got error 'Primary script unknown\n'

Этот сервер использует Apache 2.4.6 (Centos 7) с обработкой PHP, настроенной следующим образом:

<FilesMatch \.php$>
  SetHandler "proxy:fcgi://127.0.0.1:9000"
</FilesMatch>

Мне бы очень хотелось узнать настоящее имя скрипта, так как он может содержать полезную информацию (например, указание на неисправную ссылку, ошибку в названии страницы или просто указание на то, что это просто очередной дурак, охотящийся за сервером с незащищенным wp-login.php).

Я попробовал изменить LogLevel с info на debug, но тогда журнал ошибок также был заполнен действительными данными доступа к PHP-скрипту, что сильно запутало журнал ошибок, поскольку на самом деле это не ошибки.

Есть ли способ получить более полезное сообщение об ошибке proxy_fcgi, которое включает фактическое имя скрипта для несуществующих PHP-скриптов?

решение1

Вы можете определить ErrorLogFormat, включая %L, а затем сделать то же самое в вашем формате CustomLog %L

Это создаст в журнале Apache определенный идентификатор, который свяжет запись errorlog с записью журнала доступа, и затем все, что вам нужно будет сделать, это выполнить grep.

Пример:

ErrorLogFormat "[%{u}t] [%-m:%l] [%L] [pid %P:tid %T] %7F: %E: [client\ %a] %M% ,\ referer\ %{Referer}i"

LogFormat "%h %l %u [%L] %t \"%r\" %>s \"%{Referer}i\" \"%{User-Agent}i\"" combined

Так что в следующий раз, когда вы увидите ошибку, проверьте идентификатор в ней и выполните grep access.log на предмет того же идентификатора.

решение2

Я бы получил время зарегистрированной ошибки, а затем поискал бы в журнале доступа около этого времени запросы, которые возвращают ошибку. Это должно помочь отследить скрипт.

решение3

Ошибка, о которой идет речь, исходит от приложения FastCGI (того, что слушает порт 9000), а не от Apache. Apache просто сообщает о том, что возвращается в FCGI_STDERRпотоке FastCGI.

Если Apache общается с PHP-FPM (что кажется вероятным), вы можете посмотреть логи PHP-FPM. Вы можете проверить директиву error_logв вашем php-fpm.confфайле, чтобы узнать, где PHP-FPM регистрирует ошибки. Там должно быть больше подсказок.

решение4

Одним из решений является проверка существования файла перед его передачей обработчику, что и делает Debian по умолчанию.Файл конфигурациипредполагает.

<FilesMatch ".+\.ph(ar|p|tml)$">
    <If "-f %{REQUEST_FILENAME}">
        SetHandler "proxy:unix:/run/php/php-fpm.sock|fcgi://localhost"
    </If>
</FilesMatch>

Таким образом, если файл не существует, им займется Apache, а не PHP.

Связанный контент