Odpowiedzi:
Możesz wysyłać wartości zmiennych nginx za pomocą nagłówków. Przydatny do rozwoju.
add_header X-uri "$uri";
a w nagłówkach odpowiedzi przeglądarki zobaczysz:
X-uri:/index.php
Czasami robię to podczas rozwoju lokalnego.
Przydaje się również do stwierdzenia, czy podsekcja jest wykonywana, czy nie. Wystarczy posypać je klauzulami, aby sprawdzić, czy się przyzwyczają.
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;
...
}
Tak więc odwiedzenie adresu URL takiego jak http://www.example.com/index.php spowoduje wyzwolenie drugiego nagłówka podczas odwiedzania http://www.example.com/img/my-ducky.png spowoduje wyzwolenie poprzedniego nagłówka.
add_header
którego zwróci nagłówek, bez względu na kod odpowiedzi. Na przykład add_header X-debug-message "A php file was used" always;
powinien działać nawet dla kodu błędu 500.
Możesz zwrócić prosty ciąg jako odpowiedź HTTP:
location /
{
return 200 $document_root;
}
Możesz ustawić niestandardowy format dziennika dostępu za pomocą log_format
dyrektywy, która rejestruje zmienne, które Cię interesują.
error_log
celu debug
, dzięki czemu można zobaczyć wartość zmiennych i tego bloku, które są wykonane. Przykładerror_log file.log debug
-
w dzienniku, ale tak naprawdę są puste w kodzie nginx, nie powinieneś ich sprawdzać -
w żadnym momencie. To czasami myli użytkowników.
Inną opcją jest włączenie modułu echa podczas budowania nginx lub instalowanie OpenResty, który jest nginx w pakiecie z kilkoma rozszerzeniami (jak echo).
Następnie możesz po prostu posypać konfigurację takimi instrukcjami:
echo "args: $args"
echo_log
Opracowywana jest dyrektywa.
add_header
będzie działać tylko w przypadku pomyślnych żądań . Dokumentacja stwierdza, że można go stosować tylko do odpowiedzi o kodach 200, 204, 301, 302 lub 304. Dlatego nie można go używać do debugowania błędów HTTP.