
Quando um script php inexistente é solicitado, mod_proxy_fcgi fornece uma mensagem de erro bastante inútil, basicamente dizendo apenas
[proxy_fcgi:error] .... AH01071: Got error 'Primary script unknown\n'
Este servidor está usando Apache 2.4.6 (Centos 7), com manipulação de php configurada como:
<FilesMatch \.php$>
SetHandler "proxy:fcgi://127.0.0.1:9000"
</FilesMatch>
Eu realmente gostaria de saber o nome real do script, porque ele pode conter informações úteis (como indicar um link com defeito, um erro no nome de uma página ou apenas mostrar que é apenas mais um tolo procurando um servidor com wp-login desprotegido .php).
Tentei alterar o LogLevel de info para debug, mas o log de erros também foi preenchido com detalhes válidos de acesso ao script php, o que bagunça bastante o log de erros, já que na verdade não são erros.
Existe alguma maneira de obter uma mensagem de erro proxy_fcgi mais útil que inclua o nome real do script para scripts php inexistentes?
Responder1
Você pode definir ErrorLogFormat incluindo %L e então fazer o mesmo em seu formato CustomLog %L
Isso fará com que o Apache registre um ID específico que vinculará uma entrada do log de erros à entrada do log de acesso e então tudo que você precisa fazer é grep.
Exemplo:
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
Então, da próxima vez, quando você vir um erro, verifique o ID nele e digite o access.log para obter o mesmo ID
Responder2
Eu obteria a hora do erro registrado e, em seguida, pesquisaria no log de acesso nesse horário em busca de solicitações que retornassem uma falha. Isso deve ajudar a rastrear o script.
Responder3
O erro em questão vem do aplicativo FastCGI (o que quer que esteja escutando na porta 9000), não do Apache. O Apache está simplesmente relatando o que retorna no FCGI_STDERR
fluxo FastCGI.
Se o Apache estiver se comunicando com o PHP-FPM (como parece provável), você poderá consultar os logs do PHP-FPM. Você pode verificar a error_log
diretiva em seu php-fpm.conf
arquivo para descobrir onde o PHP-FPM está registrando erros. Deveria haver mais pistas aí.
Responder4
Uma solução é verificar se o arquivo existe antes de passá-lo para o manipulador, que é o padrão do Debian.arquivo de configuraçãosugere.
<FilesMatch ".+\.ph(ar|p|tml)$">
<If "-f %{REQUEST_FILENAME}">
SetHandler "proxy:unix:/run/php/php-fpm.sock|fcgi://localhost"
</If>
</FilesMatch>
Dessa forma, se o arquivo não existir, o Apache irá cuidar dele, em vez do PHP.