Respuestas:
Puede enviar valores variables nginx a través de encabezados. Práctico para el desarrollo.
add_header X-uri "$uri";
y verá en los encabezados de respuesta de su navegador:
X-uri:/index.php
A veces hago esto durante el desarrollo local.
También es útil para decirle si una subsección se está ejecutando o no. Solo espolvorea dentro de tus cláusulas para ver si se están acostumbrando.
location ~* ^.+.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt)$ {
add_header X-debug-message "A static file was served" always;
...
}
location ~ \.php$ {
add_header X-debug-message "A php file was used" always;
...
}
Por lo tanto, visitar una URL como http://www.example.com/index.php activará el último encabezado, mientras que visitar http://www.example.com/img/my-ducky.png activará el encabezado anterior.
add_header
que devolverá el encabezado, sin importar el código de respuesta. Entonces, por ejemplo, add_header X-debug-message "A php file was used" always;
debería funcionar incluso para el código de error 500.
Puede devolver una cadena simple como respuesta HTTP:
location /
{
return 200 $document_root;
}
Puede establecer un formato de registro de acceso personalizado utilizando la log_format
directiva que registra las variables que le interesan.
error_log
para debug
que pueda ver el valor de las variables y el bloque que se ejecutan. Ejemploerror_log file.log debug
-
en el registro, pero están realmente vacías en el código nginx, no debe verificarlas -
en ningún momento. Esto a veces confunde a los usuarios.
Otra opción es incluir el módulo echo cuando construye nginx, o instalar OpenResty, que es nginx incluido con un montón de extensiones (como echo).
Luego, simplemente puede rociar su configuración con declaraciones como:
echo "args: $args"
echo_log
directiva en desarrollo.
add_header
funcionará en solicitudes exitosas . La documentación indica que solo se puede aplicar a respuestas con códigos 200, 204, 301, 302 o 304. Por lo tanto, no se puede usar para depurar errores HTTP.