2012-01-03 16 views
30

Mam aplikację Sinatra obsługiwaną przez Unicorn i nginx przed nią. Gdy błąd aplikacji Sinatra (zwraca 500), chciałbym obsłużyć stronę statyczną, a nie domyślny "Błąd wewnętrznego serwera". Mam następującą konfigurację: nginxnginx nie wyświetla mojej strony error_page

server { 
    listen 80 default; 
    server_name *.example.com; 
    root /home/deploy/www-frontend/current/public; 

    location/{ 
    proxy_pass_header Server; 
    proxy_set_header Host $http_host; 
    proxy_redirect off; 
    proxy_set_header X-Real-IP $remote_addr; 
    proxy_set_header X-Scheme $scheme; 
    proxy_connect_timeout 5; 
    proxy_read_timeout 240; 
    proxy_pass http://127.0.0.1:4701/; 
    } 

    error_page 500 502 503 504 /50x.html; 
} 

Dyrektywa error_page jest tam, a ja sudo'd jak www-data (Ubuntu) i zweryfikowane mogę cat pliku, więc to nie jest problem pozwolenie. W powyższym pliku konfiguracyjnym i service nginx reload strona, którą otrzymuję w wyniku błędu, wciąż jest tym samym "Błąd wewnętrznego serwera".

Jaki jest mój błąd?

Odpowiedz

60

obsługuje błędy generowane przez nginx. Domyślnie nginx zwróci to, co serwer proxy zwróci niezależnie od kodu statusu HTTP.

Czego szukasz proxy_intercept_errors

Dyrektywa ta określa, czy nginx przechwyci odpowiedzi http kodów statusowych 400 i wyższe.

Domyślnie wszystkie odpowiedzi będą wysyłane tak jak są z serwera proxy.

Jeśli opcja ta jest włączona, to nginx będzie przechwytywał kody statusu, które są jawnie obsługiwane przez dyrektywę page_page. Odpowiedzi ze statusem kody, które nie są zgodne z dyrektywą error_page, będą wysyłane z niezmienionym serwerem, tak jak jest to .

+1

Wiedziałem, że to kwestia RTFM. Dziękujemy za poświęcenie czasu, aby zapewnić doskonałą odpowiedź! –

+9

Po prostu krótka notka do 4-letniej odpowiedzi - teraz 'proxy_intercept_errors' działa na błędy równe lub większe od 300. – Tisho

12

Można ustawić proxy_intercept_errors specjalnie dla tej lokalizacji

location /some/location { 
    proxy_pass_header Server; 
    proxy_set_header Host $http_host; 
    proxy_redirect off; 
    proxy_set_header X-Real-IP $remote_addr; 
    proxy_set_header X-Scheme $scheme; 
    proxy_connect_timeout 5; 
    proxy_read_timeout 240; 
    proxy_pass http://127.0.0.1:4701/; 
    proxy_intercept_errors on; # see http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_intercept_errors 

    error_page 400 500 404 ... other statuses ... =200 /your/path/for/custom/errors; 
} 

i można ustawić zamiast 200 inny status, co trzeba

+5

Użycie' proxy_intercept_errors; '(bez argumentu) nie jest już poprawne w bieżącym nginx. Zamiast tego użyj 'proxy_intercept_errors on;'. – Marian

+0

Cześć Marian, dziękuję za uzyskanie – Alexey

+0

Szybkie pytanie dotyczące semantyki tutaj ... Ustawienie 'proxy_intercept_errors' na' on' oznacza, że ​​strona niestandardowa jest zwracana, a ustawienie 'off' oznacza, że ​​strona nginx jest zwracana, prawda? – speedplane

0

Jak wspomniano przez Stefana in this response korzystając proxy_intercept_errors on; może pracować. choć w moim przypadku, jak widać in this answer korzystając uwsgi_intercept_errors on; wystarczyły ...

0

Ludzie, którzy używają ich jako FastCGI upstream potrzeby tego parametru włączone

fastcgi_intercept_errors on; 

dla mojej aplikacji PHP używam w moim górnym bloku konfiguracyjnym

location ~ .php$ { ## Execute PHP scripts 
    fastcgi_pass php-upstream; 
    fastcgi_intercept_errors on; 
    error_page 500 /500.html; 
} 
Powiązane problemy