2014-06-27 40 views
48

Sto usando Nginx come reverse proxy che prende le richieste poi fa un proxy_pass per ottenere l'applicazione web reale dal server upstream in esecuzione sulla porta 8001.Nginx proxy inverso causando 504 Gateway Timeout

Se vado a MyWebsite. com o fare un wget, ottengo un timeout del gateway 504 dopo 60 secondi ... Tuttavia, se carico mywebsite.com:8001, l'applicazione si carica come previsto!

nginx Quindi qualcosa è non consentire di comunicare con il server upstream ...

tutto questo è cominciato dopo la mia società di hosting resettare la macchina la mia roba era in esecuzione, prima che i problemi che cosa così mai.

Ecco il mio blocco del server vhosts:

server { 

     listen 80; 
     server_name mywebsite.com; 

     root /home/user/public_html/mywebsite.com/public; 

     access_log /home/user/public_html/mywebsite.com/log/access.log upstreamlog; 
     error_log /home/user/public_html/mywebsite.com/log/error.log; 

     location/{ 

        proxy_pass http://xxx.xxx.xxx.xxx:8001; 
        proxy_redirect off; 
        proxy_set_header Host $host; 
        proxy_set_header X-Real-IP $remote_addr; 
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 

        } 

     } 

E l'uscita dal mio Nginx log degli errori:

2014/06/27 13:10:58 [errore] 31406 # 0 : * 1 upstream scaduto (110: Connessione scaduta) durante la connessione a upstream, client: xxx.xx.xxx.xxx, server: mywebsite.com, richiesta: "GET/HTTP/1.1", a monte: "http://xxx.xxx.xxx.xxx:8001/", host: "mywebsite.com"

+0

Il server su cui è in esecuzione SELinux? – CrackerJack9

risposta

86

Probabilmente è possibile aggiungere qualche riga in più per aumentare il periodo di timeout a monte. Gli esempi che seguono imposta il timeout a 300 secondi:

proxy_connect_timeout  300; 
proxy_send_timeout   300; 
proxy_read_timeout   300; 
send_timeout    300; 
+0

Penso che aumentare il timeout sia raramente la risposta a meno che tu non sappia che la tua rete/servizio sarà sempre o in alcuni casi risponderà molto lentamente. Poche richieste web al giorno d'oggi dovrebbero richiedere più di qualche secondo a meno che tu non stia scaricando contenuti (file/immagini) – Almund

+0

@Almund ho pensato la stessa cosa (quasi non mi sono preoccupato di provarlo), ma per qualche ragione questo ha funzionato per me. (Scaduto in precedenza dopo 60 secondi, ora riceve immediatamente la risposta). –

+0

@Dax Fohl: È curioso. Ho tirato giù la fonte e ho avuto un rapido sguardo e da quello che posso vedere, l'impostazione di qualsiasi proxy_ l'impostazione a parte il proxy_pass inizializzerà un gruppo di impostazioni che presumo eseguiranno il proxy in un modo diverso, quindi forse l'impostazione di qualcosa darà lo stesso comportamento. – Almund

20

Aumentare il timeout non sarà probabilmente risolvere il problema dal momento che, come dici tu, il server di destinazione web attuale sta rispondendo bene.

Ho avuto lo stesso problema e ho trovato che aveva a che fare con non utilizzare un keep-alive sulla connessione. Non posso rispondere in realtà il motivo per cui questo non è che, in compensazione l'intestazione di connessione ho risolto questo problema e la richiesta è stata proxied bene:

server { 
    location/{ 
     proxy_set_header X-Real-IP $remote_addr; 
     proxy_set_header Host  $http_host; 
     proxy_http_version 1.1; 
     proxy_set_header Connection ""; 
     proxy_pass http://localhost:5000; 
    } 
} 

Dai un'occhiata alla questo post che spiega in modo più dettagliato: nginx close upstream connection after request Keep-alive header clarification http://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive

+0

questa è la buona risposta – yzT

+1

MESI di problemi risolti da una sola riga 'proxy_set_header Connessione" ",' lol, non usare runcloud – nodws