Bagaimana untuk menyelesaikan ralat nginx 502 Bad Gateway

Syarat pencetus untuk nginx 502

Kejadian paling biasa bagi ralat 502 ialah hos bahagian belakang ranap. Terdapat konfigurasi sedemikian dalam konfigurasi huluan: proxy_next_upstream Konfigurasi ini menentukan jenis ralat yang dihadapi oleh nginx semasa mengambil data daripada hos bahagian belakang Ia akan pergi ke hos belakang seterusnya 502s yang akan muncul Bergantung pada situasi, lalai ialah tamat masa ralat. Ralat merujuk kepada ranap, terputus sambungan, dsb. Tamat masa merujuk kepada tamat masa menyekat baca, yang lebih mudah difahami. Saya biasanya menulis semuanya:

proxy_next_upstream tamat masa invalid_header http_500 http_503 Tetapi sekarang saya mungkin perlu mengalih keluar item http_500 menyatakan bahawa apabila bahagian belakang mengembalikan ralat 500, ia akan dipindahkan ke hos ralat jsp Jika ya, sekumpulan mesej ralat surih tindanan akan dicetak, tetapi kini ia telah digantikan dengan 502. Tetapi pengaturcara syarikat tidak fikir begitu Mereka percaya bahawa terdapat ralat dalam nginx Saya benar-benar tidak mempunyai masa untuk menerangkan kepada mereka prinsip 502...

503 ralat boleh dikekalkan. kerana bahagian belakang selalunya adalah apache resin Jika apache ranap, ia akan menjadi ralat, tetapi jika resin ranap, ia hanya akan menjadi 503, jadi ia masih perlu untuk mengekalkannya.

Penyelesaian

Apabila menghadapi masalah 502, anda boleh memberi keutamaan untuk mengikuti dua langkah berikut untuk menyelesaikannya.

1. Semak sama ada bilangan proses php fastcgi semasa sudah mencukupi:

Salin kod Kod adalah seperti berikut:

netstat -anpo | " | wc -l

Jika "bilangan proses fastcgi" sebenar yang digunakan adalah hampir dengan "bilangan proses fastcgi" yang telah ditetapkan, maka ini bermakna "bilangan proses fastcgi" tidak mencukupi dan perlu ditingkatkan.

2. Masa pelaksanaan beberapa program PHP melebihi masa menunggu nginx Anda boleh meningkatkan masa tamat masa fastcgi dalam fail konfigurasi nginx.conf, contohnya:

Salin. kod Kodnya adalah seperti berikut:

http {
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
...
...
}

Jika memory_limit dalam php.ini ditetapkan rendah, ralat akan berlaku. mempunyai ingatan yang tidak mencukupi.

　

Jika pengubahsuaian ini tidak menyelesaikan masalah, anda boleh merujuk kepada penyelesaian berikut:

1 max-children and max-requests

Satu nginx php (fpm) xcache sedang berjalan pada pelayan, dan purata bilangan lawatan setiap hari ialah kira-kira 300w pv.

Baru-baru ini, situasi ini sering berlaku: halaman PHP dibuka dengan sangat perlahan, penggunaan CPU tiba-tiba menurun ke tahap yang sangat rendah, beban sistem tiba-tiba meningkat ke tahap yang sangat tinggi, dan jika anda menyemak trafik kad rangkaian, anda juga akan mendapati bahawa ia tiba-tiba jatuh ke tahap yang sangat rendah. Keadaan ini berlangsung hanya beberapa saat sebelum berbalik.

Menyemak fail log php-fpm menemui beberapa petunjuk.

Salin kod Kod adalah seperti berikut:

sep 30 08:32:23.289973 [notis] fpm_unix_init_main(), baris 271: getrlimit(nofile): maks:51200, cur:51200 30 08: 32:23.290212 [notis] fpm_sockets_init_main(), baris 371: menggunakan soket yang diwarisi fd=10, “127.0.0.1:9000″ sep 30 08:32:23.290342_notis:1]initvent_e [notis] epoll sep 30 08:32:23.296426 [notis] fpm_init(), baris 47: fpm sedang berjalan, pid 30587　

Sebelum ayat ini, terdapat lebih daripada 1,000 baris log untuk penutup kanak-kanak dan pembukaan kanak-kanak.

Ternyata php-fpm mempunyai parameter max_requests, yang menentukan bilangan maksimum permintaan yang boleh dikendalikan oleh setiap kanak-kanak sebelum ditutup Tetapan lalai ialah 500. Oleh sebab tinjauan pendapat PHP meminta setiap kanak-kanak, dalam keadaan trafik yang padat, setiap kanak-kanak mengambil masa yang lebih kurang sama untuk mencapai max_requests, yang menyebabkan semua kanak-kanak ditutup pada asasnya pada masa yang sama.

Dalam tempoh ini, nginx tidak boleh memindahkan fail php ke php-fpm untuk diproses, jadi cpu akan jatuh ke tahap yang sangat rendah (tidak perlu memproses php, apatah lagi melaksanakan sql), dan beban akan naik ke tahap yang sangat tinggi (tutup dan Hidupkan kanak-kanak, nginx menunggu php-fpm), dan trafik kad rangkaian juga dikurangkan kepada sangat rendah (nginx tidak boleh menjana data untuk dihantar kepada pelanggan)

The penyelesaian kepada masalah adalah sangat mudah, tingkatkan bilangan kanak-kanak, dan tetapkan max_requests kepada kurang daripada 0 atau A nilai yang agak besar:

Buka /usr/local/php/etc/php-fpm.conf dan tingkatkan dua parameter berikut (mengikut situasi sebenar pelayan, terlalu besar tidak akan berfungsi)

Salin kod Kod adalah seperti berikut:

600　

Kemudian mulakan semula php-fpm.

2. Tingkatkan kapasiti penimbal

Buka log ralat nginx dan cari mesej ralat seperti "pstream menghantar pengepala terlalu besar semasa membaca pengepala respons dari hulu". Selepas menyemak maklumat, idea umum ialah terdapat pepijat dalam penimbal nginx Penampan yang diduduki oleh penggunaan halaman laman web kami mungkin terlalu besar. Merujuk kepada kaedah pengubahsuaian yang ditulis oleh orang asing, tetapan kapasiti penimbal ditingkatkan, dan masalah 502 diselesaikan sepenuhnya. Kemudian, pentadbir sistem melaraskan parameter dan mengekalkan hanya dua parameter tetapan: penimbal kepala klien dan saiz penimbal fastcgi.

3. minta_tamat_masa

Jika 502 berlaku terutamanya semasa beberapa siaran atau operasi pangkalan data, dan bukannya biasa dalam operasi halaman statik, maka anda boleh menyemak salah satu tetapan php-fpm.conf:

request_terminate_timeout

Ini nilai ialah max_execution_time, iaitu masa skrip pelaksanaan fast-cgi.

0s

0s ditutup, yang bermaksud ia akan terus dilaksanakan selama-lamanya. (Saya menukar nombor tanpa melihat dengan teliti semasa pemasangan) Masalah telah diselesaikan dan pelaksanaan akan bebas ralat untuk masa yang lama. Dalam mengoptimumkan fastcgi, anda juga boleh menukar nilai ini selama 5 saat untuk melihat kesannya.

Jika bilangan proses php-cgi tidak mencukupi, masa pelaksanaan php adalah panjang, atau proses php-cgi mati, ralat 502 akan berlaku.

Penyelesaian 2 untuk ralat get laluan nginx 502

Hari ini, vps saya kerap menggesa ralat get laluan nginx 502 selepas memulakan semula vps, ia sangat menjengkelkan . Saya agak keliru. Tapak web ini mempunyai 1290 lawatan dalam dua hari yang lalu tanpa sebarang masalah. menyedihkan! ! ! Setelah sekian lama mencari, akhirnya saya dapati banyak jawapan yang relevan. Saya harap ralat ini tidak akan berlaku lagi selepas pengubahsuaian. Alamak, sejak sekian lama saya mencari jawapan dalam talian, sudah tentu saya perlu merakam perkara yang berguna supaya saya tidak perlu pergi ke Google lagi pada masa akan datang~

Sejak saya menggunakan yang lnmp -klik pakej pemasangan, ada yang tidak kena Anda mesti pergi ke forum rasmi dan mencarinya.

Pakej pemasangan satu klik lnmp rasmi:

Sebab pertama: Pada masa ini, masalah paling biasa dengan pakej pemasangan satu klik lnmp ialah 502 get laluan yang tidak baik memasang php. , beberapa pakej lib dalam skrip mungkin tidak dipasang, menyebabkan PHP tidak berjaya disusun dan dipasang.
Penyelesaian: Anda boleh cuba memasangnya secara manual mengikut skrip dalam pakej pemasangan satu klik lnmp untuk melihat apa yang menyebabkan ralat.

Sebab kedua:

Dalam php.ini, item konfigurasi eccelerator mesti diletakkan sebelum konfigurasi zend optimizer, jika tidak, ia juga boleh menyebabkan 502 get bad

Yang ketiga Sebab Sebab:

Masalah 502 berlaku semasa pemasangan dan penggunaan Secara amnya, ia adalah kerana proses php-cgi lalai ialah 5. 502 mungkin disebabkan oleh proses phpcgi yang tidak mencukupi diubah suai. Tingkatkan nilai max_children dengan sewajarnya dalam etc/php-fpm.conf.

Sebab keempat:

Tamat masa pelaksanaan PHP, ubah suai /usr/local/php/etc/php.ini untuk menukar max_execution_time kepada 300

Sebab kelima:

Ruang cakera tidak mencukupi, seperti log mysql mengambil banyak ruang

Sebab keenam:

Periksa sama ada proses php-cgi sedang berjalan

Sesetengah netizen juga memberikan Terdapat satu lagi penyelesaian:

nginx 502 bad gateway bermakna php-cgi yang diminta telah dilaksanakan, tetapi atas sebab tertentu (biasanya masalah membaca sumber) ia tidak dilaksanakan, mengakibatkan php- cgi Proses ditamatkan Secara umumnya, nginx 502 bad gateway adalah berkaitan dengan tetapan php-fpm.conf.

php-fpm.conf mempunyai dua parameter penting, satu ialah max_children dan satu lagi ialah request_terminate_timeout, tetapi nilai ini tidak universal dan perlu dikira sendiri.
Masalah 502 berlaku semasa pemasangan dan penggunaan Ia biasanya kerana proses php-cgi lalai ialah 5. Mungkin proses phpcgi tidak mencukupi untuk menyebabkan 502. /usr/local/php/etc/php-. fpm perlu diubah suai conf akan meningkatkan nilai max_children dengan sewajarnya.

Kaedah pengiraan adalah seperti berikut:

Jika prestasi pelayan anda cukup baik, sumber jalur lebar adalah mencukupi, dan tiada gelung atau pepijat dalam skrip php, anda boleh terus menetapkan request_terminate_timeout kepada 0s. Maksud 0s ialah membiarkan php-cgi terus dilaksanakan tanpa had masa. Dan jika anda tidak boleh melakukan ini, iaitu, php-cgi anda mungkin mempunyai pepijat, atau lebar jalur anda tidak mencukupi, atau sebab lain menyebabkan php-cgi anda membeku, maka anda disyorkan untuk menetapkan nilai untuk request_terminate_timeout Nilai ini boleh ditetapkan mengikut prestasi pelayan. Secara umumnya, lebih baik prestasi, lebih tinggi anda boleh menetapkannya, di mana-mana dari 20 minit hingga 30 minit.
Bagaimanakah nilai max_children dikira? Pada dasarnya, lebih besar nilai, lebih baik Jika terdapat lebih banyak proses php-cgi, ia akan diproses dengan cepat dan akan terdapat lebih sedikit permintaan beratur. Menetapkan max_children juga perlu ditetapkan mengikut prestasi pelayan Secara umumnya, memori yang digunakan oleh setiap php-cgi pada pelayan adalah kira-kira 20m dalam keadaan biasa.

Berikutan jawapan rasmi, kami menyiasat kemungkinan yang berkaitan dan digabungkan dengan jawapan daripada netizen, kami menghasilkan penyelesaian berikut.

1. Semak bilangan proses php fastcgi (nilai max_children)

Kod: netstat -anpo | jika dipaparkan 5)

2 Semak proses semasa

Kod: atas

Perhatikan bilangan proses fastcgi jika bilangan proses yang digunakan adalah sama dengan atau lebih daripada 5, ia bermakna ia perlu ditingkatkan (mengikut situasi sebenar mesin anda) (Bergantung pada situasi)

3 Laraskan tetapan /usr/local/php/etc/php-fpm.conf yang berkaitan

1060s

maks_children boleh mempunyai sehingga 10 proses dengan memori 20mb setiap proses, sehingga 200mb.
Masa pelaksanaan request_terminate_timeout ialah 60 saat, iaitu 1 minit.

Atas ialah kandungan terperinci Bagaimana untuk menyelesaikan ralat nginx 502 Bad Gateway. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!