nginx 502 gateway errato

Ottengo un 502 Bad Gateway con nginx quando si usa spawn fcgi per generare php5-cgi.

Lo uso per estendere un'istanza all'avvio del server utilizzando la seguente row in rc.local

/usr/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -u www-data -g www-data -f /usr/bin/php5-cgi -P /var/run/fastcgi-php.pid 

presumibilmente sto ricevendo l'errore perché muore lo spawn-fcgi / php5-cgi e non c'è più niente da ascoltare lì per analizzare php.

Non trovo nulla nei log che riesco a vedere da nessuna parte, sono fuori di idee (e nuovo in questa configuration con nginx)

Ho avuto lo stesso problema. Ho eseguito il mio localhost e la pagina ha visualizzato il messaggio 502 bad gateway valido. Questo mi ha aiutato:

Vai a /etc/php5/fpm/pool.d/www.conf e modifica la row listen = /var/run/php5-fpm.sock per listen = 127.0.0.1:9000

Forse ti aiuterà.

Fonte da: http://wildlyinaccurate.com/solving-502-bad-gateway-with-nginx-php-fpm

L'errore 502 appare perché nginx non può passare a php5-cgi. Puoi provare a riconfigurare php5-cgi per usare socket unix invece di tcp .. quindi regola la configuration del server in modo che punti al socket invece del tcp …

 ps auxww | grep php5-cgi #-- is the process running? netstat -an | grep 9000 # is the port open? 

Vai a /etc/php5/fpm/pool.d/www.conf e se stai usando i socket o questa linea non è commentata

 listen = /var/run/php5-fpm.sock 

Imposta anche una coppia di altri valori: –

 listen.owner = www-data listen.group = www-data listen.mode = 0660 

Non dimenticare di riavviare php-fpm e nginx. Assicurati di utilizzare lo stesso proprietario e il nome del gruppo Nginx.

Devi abbinare le impostazioni per PHP-FPM e Nginx per comunicare su socket o TCP.

Quindi vai su /etc/php5/fpm/pool.d/www.conf e cerca questa linea:

 listen = /var/run/php5-fpm.sock 

Quindi vai su /etc/nginx/nginx.conf

Cerca questo:

 upstream php { server unix:/var/run/php5-fpm.socket; } 

Abbina quei valori e dovresti essere tutto pronto.

Se stai usando un server Linux, assicurati che la configuration di IPTABLES sia corretta.

Esegui sudo iptables -L -n , riceverai un elenco delle tue porte aperte. Se non esiste una regola Iptables per aprire la port che serve lo script fcgi, si riceverà un errore 502. La regola Iptables che apre la port corretta deve essere elencata prima di qualsiasi regola che rifiuta categoricamente tutti i pacchetti (cioè una regola del module "REJECT ALL -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable or simile)

Sulla mia configuration, per aprire correttamente la port, ho dovuto eseguire questo command (supponiamo che il mio server fcgi stia girando sulla port 4567):

 sudo iptables -I INPUT 1 -p tcp --dport 4567 -j ACCEPT 

ATTENZIONE: questo aprirà la port 4567 in tutto il mondo.

Quindi potrebbe essere meglio fare qualcosa del genere:

  sudo iptables-save >> backup.iptables sudo iptables -D INPUT 1 #Delete the previously entered rule sudo iptables -I INPUT 1 -p tcp --dport 8080 -s localhost -j ACCEPT # Add new rule 

In questo modo ho rimosso l'errore 502 per me.

modificare

 fastcgi_pass unix:/var/run/php-fpm.sock; 

a

 fastcgi_pass unix:/var/run/php5-fpm.sock; 

Quando ho fatto sudo /etc/init.d/php-fpm start ho ricevuto il seguente errore:

 Starting php-fpm: [28-Mar-2013 16:18:16] ERROR: [pool www] cannot get uid for user 'apache' 

Immagino che /etc/php-fpm.d/www.conf bisogno di sapere all'utente che il webserver è in esecuzione e presume che sia apache quando, per nginx, è in realtà nginx e deve essere cambiato.

Puoi fare in modo che nginx ignori le interruzioni del client usando:

 location / { proxy_ignore_client_abort on; } 

Prova a disabilitare i moduli xcache o apc. Sembra causare problemi con alcune versioni stanno salvando oggetti su una variabile di session.

Spero che questo suggerimento salvi la vita di qualcun altro. Nel mio caso il problema era che avevo esaurito la memory, ma solo leggermente, era difficile pensarci. Wasted 3 ore su questo. Raccommand di correre:

 sudo htop 

o

 sudo free -m 

… insieme all'esecuzione di richieste problematiche sul server per vedere se la memory non si esaurisce. E se nel mio caso lo fa, è necessario creare un file di scambio (a less che non ne abbiate già uno).

Ho seguito questo tutorial per creare il file di swap su Ubuntu Server 14.04 e ha funzionato bene: http://www.cyberciti.biz/faq/ubuntu-linux-create-add-swap-file/

Ho avuto lo stesso problema durante la configuration di un server Ubuntu. Risulta che stavo avendo il problema a causa di autorizzazioni errate sul file socket.

Se si verifica il problema a causa di un problema di authorization, è ansible rimuovere il commento dalle righe seguenti: /etc/php5/fpm/pool.d/www.conf

 listen.owner = www-data listen.group = www-data listen.mode = 0660 

In alternativa, sebbene non lo consiglierei, puoi dare permessi di lettura e scrittura a tutti i gruppi usando il seguente command.

 sudo chmod go+rw /var/run/php5-fpm.sock 

Se sei su Ubuntu e tutto quanto sopra ti ha deluso, è probabile che AppArmor sia la colpa.

Ecco una buona guida su come risolverlo: https://www.digitalocean.com/community/tutorials/how-to-create-an-apparmor-profile-for-nginx-on-ubuntu-14-04

Per farla breve:

 vi /etc/apparmor.d/nginx 

O

 sudo aa-complain nginx sudo service nginx restart 

Vedi tutto funziona bene … allora

 sudo aa-logprof 

Ho ancora avuto problemi con Nginx che non riusciva a leggere error.log, anche se aveva tutte le autorizzazioni possibili, incluso in Apparomor. Immagino che abbia qualcosa a che fare con l'ordine delle voci, o qualche interazione con Passenger o PHP-Fpm … Ho perso tempo per risolvere questo problema e sono tornato ad Apache per ora. (Anche Apache si comport molto meglio).

AppArmor consente a Nginx di fare ciò che vuole, basta rimuovere il profilo:

  rm /etc/apparmor.d/nginx service apparmor reload 

Sorprendentemente, ma non sorprende, molti post sulla correzione degli errori di Nginx ricorrono alla disabilitazione completa di SELinux o alla rimozione di AppArmor. Questa è una ctriggers idea perché si perde la protezione da un sacco di software. Basta rimuovere il profilo Nginx è un modo migliore per risolvere i tuoi file di configuration. Una volta che sai che il problema non è nei tuoi file di configuration Nginx, puoi prendere il tempo necessario per creare un profilo AppArmor appropriato.

Senza un profilo AppArmor, specialmente se gestisci qualcosa come Passenger, do al tuo server circa un mese per fare backdoor.

Configurazione simile qui e sembra che fosse solo un bug nel mio codice. All'inizio della mia app ho cercato l'URL offensivo e questo ha funzionato: echo '<html>test</html>'; exit(); echo '<html>test</html>'; exit();

Nel mio caso, il problema era una variabile non inizializzata che falliva solo in circostanze particolari.