สาเหตุที่เป็นไปได้สำหรับรหัสข้อผิดพลาด NGINX 499

ฉันได้รับรหัสข้อผิดพลาด 499 NGINX จำนวนมาก ฉันเห็นว่านี่เป็นปัญหาจากฝั่งไคลเอ็นต์ ไม่ใช่ปัญหากับ NGINX หรือ uWSGI stack ของฉัน ฉันสังเกตความสัมพันธ์ในบันทึก uWSGI เมื่อได้รับ 499

address space usage: 383692800 bytes/365MB} {rss usage: 167038976
bytes/159MB} [pid: 16614|app: 0|req: 74184/222373] 74.125.191.16 ()
{36 vars in 481 bytes} [Fri Oct 19 10:07:07 2012] POST /bidder/ =>
generated 0 bytes in 8 msecs (HTTP/1.1 200) 1 headers in 59 bytes (1
switches on core 1760)
SIGPIPE: writing to a closed pipe/socket/fd (probably the client
disconnected) on request /bidder/ (ip 74.125.xxx.xxx) !!!
Fri Oct 19 10:07:07 2012 - write(): Broken pipe [proto/uwsgi.c line
143] during POST /bidder/ (74.125.xxx.xxx)
IOError: write error

ฉันกำลังมองหาคำอธิบายเชิงลึกเพิ่มเติมและหวังว่าจะไม่มีอะไรผิดปกติกับการกำหนดค่า NGINX สำหรับ uwsgi ฉันใช้มันตามมูลค่า ดูเหมือนว่าเป็นปัญหาของลูกค้า

HTTP 499 ใน Nginx หมายความว่าไคลเอนต์ปิดการเชื่อมต่อก่อนที่เซิร์ฟเวอร์จะตอบคำขอ จากประสบการณ์ของผมมักจะเกิดจากการหมดเวลาฝั่งไคลเอ็นต์ อย่างที่ฉันรู้ว่ามันเป็นรหัสข้อผิดพลาดเฉพาะของ Nginx

ในกรณีของฉันฉันไม่อดทนและลงเอยด้วยการตีความบันทึกผิด

อันที่จริงปัญหาที่แท้จริงคือการสื่อสารระหว่าง nginx และ uwsgi ไม่ใช่ระหว่างเบราว์เซอร์และ nginx หากฉันโหลดไซต์ในเบราว์เซอร์และรอนานพอฉันจะได้รับ "504 - Bad Gateway" แต่ใช้เวลานานมากฉันจึงพยายามอย่างต่อเนื่องและรีเฟรชในเบราว์เซอร์ ดังนั้นฉันไม่เคยรอนานพอที่จะเห็นข้อผิดพลาด 504 เมื่อรีเฟรชในเบราว์เซอร์นั่นคือเมื่อคำขอก่อนหน้านี้ถูกปิดและ Nginx เขียนสิ่งนั้นในบันทึกเป็น 499

รายละเอียดเพิ่มเติม

ในที่นี้ฉันจะถือว่าผู้อ่านรู้น้อยที่สุดเท่าที่ฉันเคยทำเมื่อฉันเริ่มเล่น

การตั้งค่าของฉันคือ reverse proxy เซิร์ฟเวอร์ nginx และแอ็พพลิเคชันเซิร์ฟเวอร์เซิร์ฟเวอร์ uWSGI ที่อยู่เบื้องหลัง คำขอทั้งหมดจากไคลเอนต์จะไปที่เซิร์ฟเวอร์ nginx จากนั้นส่งต่อไปยังเซิร์ฟเวอร์ uWSGI จากนั้นการตอบกลับจะถูกส่งกลับในลักษณะเดียวกัน ฉันคิดว่านี่เป็นวิธีที่ทุกคนใช้ nginx / uwsgi และควรใช้

nginx ของฉันทำงานได้ตามที่ควร แต่มีบางอย่างผิดปกติกับเซิร์ฟเวอร์ uwsgi มีสองวิธี (อาจมากกว่านั้น) ที่เซิร์ฟเวอร์ uwsgi ไม่สามารถตอบสนองต่อเซิร์ฟเวอร์ nginx ได้

1) uWSGI กล่าวว่า "ฉันกำลังดำเนินการรอเพียงไม่นานคุณจะได้รับคำตอบ" nginx มีช่วงเวลาหนึ่งที่ยินดีที่จะรอ fx 20 วินาที หลังจากนั้นจะตอบกลับไปยังไคลเอนต์โดยมีข้อผิดพลาด 504

2) uWSGI ตายแล้วหรือ uWSGi ตายในขณะที่ nginx กำลังรออยู่ nginx จะเห็นทันทีและในกรณีนั้นจะส่งกลับข้อผิดพลาด 499

ฉันกำลังทดสอบการตั้งค่าของฉันโดยการร้องขอในไคลเอนต์ (เบราว์เซอร์) ในเบราว์เซอร์ไม่มีอะไรเกิดขึ้นมันก็ยังคงค้างอยู่ หลังจากผ่านไป 10 วินาที (น้อยกว่าการหมดเวลา) ฉันสรุปว่ามีบางอย่างไม่ถูกต้อง (ซึ่งเป็นความจริง) และปิดเซิร์ฟเวอร์ uWSGI จากบรรทัดคำสั่ง จากนั้นฉันจะไปที่การตั้งค่า uWSGI ลองอะไรใหม่ ๆ แล้วรีสตาร์ทเซิร์ฟเวอร์ uWSGI ขณะที่ฉันปิดเซิร์ฟเวอร์ uWSGI เซิร์ฟเวอร์ nginx จะส่งคืนข้อผิดพลาด 499

ดังนั้นฉันจึงทำการดีบักด้วย 499 erroe ซึ่งหมายถึง googling สำหรับข้อผิดพลาด 499 แต่ถ้าฉันรอนานพอฉันจะได้รับข้อผิดพลาด 504 หากฉันได้รับข้อผิดพลาด 504 ฉันจะเข้าใจปัญหาได้ดีขึ้นจากนั้นจึงสามารถดีบักได้

สรุปได้ว่าปัญหาเกิดจาก uWGSI ซึ่งยังคงค้างอยู่ ("รออีกหน่อยเดี๋ยวฉันจะมีคำตอบให้ ... ")

ฉันคงว่าปัญหาผมจำไม่ได้ ฉันเดาว่ามันอาจเกิดจากหลายสิ่งหลายอย่าง

ลูกค้าปิดการเชื่อมต่อไม่ได้หมายความว่าเป็นปัญหาของเบราว์เซอร์!? ไม่ใช่เลย!

คุณสามารถพบข้อผิดพลาด 499 รายการในไฟล์บันทึกหากคุณมี LB (ตัวโหลดบาลานเซอร์) ที่หน้าเว็บเซิร์ฟเวอร์ (nginx) ทั้ง AWS หรือ haproxy (กำหนดเอง) ที่กล่าวว่า LB จะทำหน้าที่เป็นลูกค้าของ nginx

หากคุณรันค่าเริ่มต้น haproxy สำหรับ:

    timeout client  60000
    timeout server  60000

นั่นหมายความว่า LB จะหมดเวลาหลังจาก 60000ms หากไม่มีการตอบสนองจาก nginx การหมดเวลาอาจเกิดขึ้นสำหรับเว็บไซต์ที่มีงานยุ่งหรือสคริปต์ที่ต้องการเวลาในการดำเนินการมากขึ้น คุณจะต้องหาระยะหมดเวลาที่เหมาะกับคุณ ตัวอย่างเช่นขยายเป็น:

    timeout client  180s
    timeout server  180s

และคุณอาจจะตั้ง

ขึ้นอยู่กับการตั้งค่าของคุณคุณอาจเห็นข้อผิดพลาดการหมดเวลาเกตเวย์ 504 ในเบราว์เซอร์ของคุณซึ่งบ่งชี้ว่ามีบางอย่างผิดปกติกับ php-fpm แต่จะไม่เป็นเช่นนั้นกับข้อผิดพลาด 499 รายการในไฟล์บันทึกของคุณ

ในขณะที่คุณชี้499การแท้งเชื่อมต่อที่บันทึกโดย nginx แต่โดยปกติแล้วจะเกิดขึ้นเมื่อเซิร์ฟเวอร์แบ็กเอนด์ของคุณทำงานช้าเกินไปและพร็อกซีอื่นหมดเวลาก่อนหรือซอฟต์แวร์ของผู้ใช้จะยกเลิกการเชื่อมต่อ ดังนั้นตรวจสอบว่า uWSGI ตอบรับอย่างรวดเร็วหรือไม่ว่ามีการโหลดบนเซิร์ฟเวอร์ uWSGI / ฐานข้อมูลหรือไม่

ในหลาย ๆ กรณีมีพร็อกซีอื่น ๆ ระหว่างผู้ใช้และ nginx บางอย่างอาจอยู่ในโครงสร้างพื้นฐานของคุณเช่น CDN, Load Balacer, Varnish cache เป็นต้นอื่น ๆ สามารถอยู่ในฝั่งผู้ใช้เช่น caching proxy เป็นต้น

หากมีพร็อกซีอยู่เคียงข้างคุณเช่น LoadBalancer / CDN ... คุณควรตั้งค่าการหมดเวลาเป็นระยะหมดเวลาก่อนแบ็กเอนด์ของคุณและส่งมอบพร็อกซีอื่น ๆ ให้กับผู้ใช้

ถ้าคุณมี:

user >>> CDN >>> Load Balancer >>> Nginx >>> uWSGI

ฉันจะแนะนำให้คุณตั้งค่า:

• n วินาทีจะหมดเวลา uWSGI
• n+1 วินาทีที่จะหมดเวลา nginx
• n+2 senconds เพื่อหมดเวลาในการโหลดบาลานเซอร์
• n+3 วินาทีของการหมดเวลาไปยัง CDN

หากคุณไม่สามารถตั้งค่าการหมดเวลาบางส่วน (เช่น CDN) ให้ค้นหาว่าการหมดเวลาคืออะไรและปรับค่าอื่น ๆ ตาม ( n, n-1... )

สิ่งนี้จัดเตรียมสายการหมดเวลาที่ถูกต้อง และคุณจะพบว่าใครให้การหมดเวลาและส่งคืนรหัสตอบกลับที่ถูกต้องให้กับผู้ใช้

ในกรณีของฉันฉันได้รับ 499 เมื่อ API ของไคลเอนต์ปิดการเชื่อมต่อก่อนที่จะได้รับการตอบสนองใด ๆ ส่ง POST ตามตัวอักษรและปิดการเชื่อมต่อทันที สิ่งนี้แก้ไขได้โดยตัวเลือก:

proxy_ignore_client_abort บน

เอกสาร Nginx

ปรากฎว่า 499 หมายถึง "ไคลเอนต์ขัดจังหวะการเชื่อมต่อ" จริงๆ

ฉันมีไคลเอนต์อ่านหมดเวลา 60 (และ nginx ยังมี proxy_read_timeout เริ่มต้นเป็น 60s) ดังนั้นสิ่งที่เกิดขึ้นในกรณีของฉันคือ nginx จะ error.log upstream timed out (110: Connection timed out) while reading upstreamและจากนั้น nginx จะลอง "พร็อกซีเซิร์ฟเวอร์ถัดไปในกลุ่มเซิร์ฟเวอร์แบ็กเอนด์ที่คุณกำหนดค่า" นั่นคือถ้าคุณมีมากกว่าหนึ่ง

จากนั้นมันจะพยายามครั้งต่อไปและถัดไปจนถึง (โดยค่าเริ่มต้น ) มันหมดแล้ว เนื่องจากแต่ละครั้งหมดเวลาจะลบออกจากรายการเซิร์ฟเวอร์แบ็กเอนด์ "สด" เช่นกัน หลังจากหมดแรงมันจะส่งกลับ a504 gateway timeout.

ดังนั้นในกรณีของฉัน nginx จึงทำเครื่องหมายเซิร์ฟเวอร์เป็น "ไม่พร้อมใช้งาน" ให้ลองใหม่ในเซิร์ฟเวอร์ถัดไปจากนั้นการ60sหมดเวลาของไคลเอ็นต์ของฉัน(ทันที) เกิดขึ้นฉันจึงเห็นupstream timed out (110: Connection timed out) while reading upstreamบันทึกตามด้วยบันทึก 499 แต่มันเป็นแค่ความบังเอิญ

ที่เกี่ยวข้อง:

หากเซิร์ฟเวอร์ทั้งหมดในกลุ่มถูกทำเครื่องหมายว่าไม่พร้อมใช้งานในขณะนี้เซิร์ฟเวอร์จะส่งคืนค่าเป็น502 Bad Gateway.10 วินาทีเช่นกัน ดูที่นี่ max_failsและ fail_timeout ในบันทึกมันจะพูดno live upstreams while connecting to upstream.

หากคุณมีพร็อกซีแบ็กเอนด์เพียงตัวเดียวในกลุ่มเซิร์ฟเวอร์ของคุณให้ลองใช้เซิร์ฟเวอร์เดียวและส่งกลับ504 Gateway Time-outและไม่ลบเซิร์ฟเวอร์เดียวออกจากรายการเซิร์ฟเวอร์ที่ "ใช้งานอยู่" หากproxy_read_timeoutเกิน ดูที่นี่ "หากมีเพียงเซิร์ฟเวอร์เดียวในกลุ่มพารามิเตอร์ max_fails, fail_timeout และ slow_start จะถูกละเว้นและเซิร์ฟเวอร์ดังกล่าวจะไม่ถูกพิจารณาว่าไม่พร้อมใช้งาน"

ส่วนที่ยุ่งยากจริงๆคือถ้าคุณระบุ proxy_pass เป็น "localhost" และกล่องของคุณมี "ตำแหน่ง" เวอร์ชัน ipv6 และ ipv4 พร้อมกันด้วย (กล่องส่วนใหญ่ทำตามค่าเริ่มต้น) ระบบจะนับว่าคุณมี "รายชื่อ" ของเซิร์ฟเวอร์หลายเครื่องในกลุ่มเซิร์ฟเวอร์ของคุณซึ่งหมายความว่าคุณสามารถเข้าสู่สถานการณ์ด้านบนโดยให้เซิร์ฟเวอร์ส่งคืน "502 for 10s" แม้ว่าคุณจะแสดงรายการเซิร์ฟเวอร์เพียงเครื่องเดียวก็ตาม ดูที่นี่ "หากชื่อโดเมนแก้ไขไปยังที่อยู่หลายแห่งจะมีการใช้ชื่อโดเมนทั้งหมดในรูปแบบการหมุนเวียน" วิธีแก้ปัญหาอย่างหนึ่งคือการประกาศเป็นproxy_pass http://127.0.0.1:5001;(ที่อยู่ ipv4) เพื่อหลีกเลี่ยงไม่ให้เป็นทั้ง ipv6 และ ipv4 จากนั้นจะนับเป็นพฤติกรรม "เฉพาะเซิร์ฟเวอร์เดียว"

มีการตั้งค่าที่แตกต่างกันสองสามอย่างที่คุณสามารถปรับแต่งเพื่อให้ "ปัญหา" น้อยลง เช่นเดียวกับการเพิ่มระยะหมดเวลาหรือทำให้เซิร์ฟเวอร์ไม่ทำเครื่องหมายเซิร์ฟเวอร์ว่า "ปิดใช้งาน" เมื่อหมดเวลา ... หรือแก้ไขรายการให้เป็นขนาด 1 เท่านั้นดูด้านบน :)

ดูเพิ่มเติม: https://serverfault.com/a/783624/27813

ข้อผิดพลาดนี้ค่อนข้างง่ายในการสร้างซ้ำโดยใช้การกำหนดค่ามาตรฐาน nginx กับ php-fpm

การกดปุ่ม F5 ไว้บนหน้าจะสร้างคำขอรีเฟรชจำนวนมากไปยังเซิร์ฟเวอร์ คำขอก่อนหน้าแต่ละรายการจะถูกยกเลิกโดยเบราว์เซอร์เมื่อรีเฟรชใหม่ ในกรณีของฉันฉันพบ 499 หลายสิบรายการในไฟล์บันทึกร้านค้าออนไลน์ของลูกค้า จากมุมมอง nginx: หากไม่มีการส่งการตอบกลับไปยังไคลเอ็นต์ก่อนที่คำขอรีเฟรชครั้งถัดไป nginx จะบันทึกข้อผิดพลาด 499

mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:32 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:33 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:33 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:33 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:33 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:34 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:34 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:34 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:34 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:35 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:35 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)

หากการประมวลผล php-fpm ใช้เวลานานขึ้น (เช่นหน้า WP ที่หนักหน่วง) อาจทำให้เกิดปัญหาได้แน่นอน ตัวอย่างเช่นฉันเคยได้ยินเกี่ยวกับปัญหา php-fpm แต่ฉันเชื่อว่าสามารถป้องกันการกำหนดค่าบริการได้อย่างเหมาะสมเช่นการจัดการการโทรไปยัง xmlrpc.php

... มาที่นี่จากการค้นหาโดย Google

ฉันพบคำตอบที่อื่นที่นี่ -> https://stackoverflow.com/a/15621223/1093174

ซึ่งเป็นการเพิ่มระยะหมดเวลาการเชื่อมต่อของ AWS elastic load balancer!

(ฉันได้ตั้งค่าไซต์ Django ด้วย nginx / apache reverse proxy และบันทึกงานแบ็กเอนด์ / การดูจริงๆก็หมดเวลา)

ฉันรู้ว่านี่เป็นกระทู้เก่า แต่ตรงกับสิ่งที่เพิ่งเกิดขึ้นกับฉันเมื่อเร็ว ๆ นี้และฉันคิดว่าฉันจะบันทึกไว้ที่นี่ การตั้งค่า (ใน Docker) มีดังนี้:

• nginx_proxy
• Nginx
• php_fpm เรียกใช้แอปจริง

อาการคือ "502 Gateway Timeout" บนพร้อมต์ล็อกอินแอปพลิเคชัน การตรวจสอบพบบันทึก:

• ปุ่มทำงานผ่าน HTTP POSTถึง/login ... และอื่น ๆ ...
• nginx-proxy ได้รับ/loginคำขอและในที่สุดก็รายงานการหมดเวลา
• nginx ส่งคืน a 499ตอบกลับซึ่งแน่นอนว่า "โฮสต์เสียชีวิต"
• /loginคำขอไม่ปรากฏที่ทุกคน (!)ในบันทึกเซิร์ฟเวอร์ FPM ของ!
• ไม่มีการย้อนกลับหรือข้อความแสดงข้อผิดพลาดใน FPM ... nada, zero, zippo, none

ปรากฎว่าปัญหาคือความล้มเหลวในการเชื่อมต่อกับฐานข้อมูลเพื่อตรวจสอบการเข้าสู่ระบบ แต่วิธีคิดนั้นกลับกลายเป็นคาดเดาอย่างแท้จริง

การไม่มีบันทึกการติดตามย้อนกลับของแอปพลิเคชันโดยสิ้นเชิง ... หรือแม้แต่บันทึกที่ FPM ได้รับคำขอ ... เป็นสิ่งที่ทำให้ฉันประหลาดใจอย่างสมบูรณ์(และทำลายล้าง ... ) ใช่แอปพลิเคชันควรบันทึกความล้มเหลว แต่ในกรณีนี้ดูเหมือนว่ากระบวนการของผู้ปฏิบัติงาน FPM เสียชีวิตด้วยข้อผิดพลาดรันไทม์ซึ่งนำไปสู่การ499ตอบสนองจาก nginx ตอนนี้เห็นได้ชัดว่าเป็นปัญหาในแอปพลิเคชันของเรา ... แต่ฉันต้องการบันทึกรายละเอียดของสิ่งที่เกิดขึ้นเพื่อประโยชน์ของคนต่อไปที่ต้องเผชิญกับสิ่งนี้

เมื่อฉันได้รับ499 "คำขอถูกห้ามโดยโปรแกรมป้องกันไวรัส"เป็นการตอบสนอง AJAX http (ผลบวกที่ผิดพลาดโดย Kaspersky Internet Security พร้อมการวิเคราะห์ฮิวริสติกแบบเบา ๆ การวิเคราะห์ฮิวริสติกอย่างละเอียดจะรู้ได้อย่างถูกต้องว่าไม่มีอะไรผิดปกติ)

ฉันพบปัญหานี้และสาเหตุเกิดจากปลั๊กอิน Kaspersky Protection บนเบราว์เซอร์ หากคุณพบปัญหานี้ให้ลองปิดการใช้งานปลั๊กอินของคุณและดูว่าสามารถแก้ไขปัญหาของคุณได้หรือไม่

หนึ่งในเหตุผลสำหรับพฤติกรรมนี้อาจเป็นคุณกำลังใช้httpสำหรับแทนuwsgi socketใช้คำสั่งด้านล่างหากคุณใช้uwsgiโดยตรง

uwsgi --socket :8080 --module app-name.wsgi

คำสั่งเดียวกันในไฟล์. ini คือ

chdir = /path/to/app/folder
socket = :8080
module = app-name.wsgi

สิ่งนี้ไม่ได้ตอบคำถาม OPs แต่เนื่องจากฉันมาที่นี่หลังจากค้นหาคำตอบอย่างดุเดือดฉันจึงต้องการแบ่งปันสิ่งที่เราค้นพบ

ในกรณีของเราคาดว่า 499s เหล่านี้ ตัวอย่างเช่นเมื่อผู้ใช้ใช้คุณลักษณะพิมพ์ล่วงหน้าในช่องค้นหาบางช่องเราจะเห็นสิ่งนี้ในบันทึก

GET /api/search?q=h [Status 499] 
GET /api/search?q=he [Status 499]
GET /api/search?q=hel [Status 499]
GET /api/search?q=hell [Status 499]
GET /api/search?q=hello [Status 200]

ดังนั้นในกรณีของเราฉันคิดว่ามันปลอดภัยที่จะใช้proxy_ignore_client_abort onซึ่งแนะนำไว้ในคำตอบก่อนหน้านี้ ขอบคุณสำหรับสิ่งนั้น!

ในส่วนของฉันฉันได้เปิดใช้งานufwแต่ฉันลืมที่จะเปิดเผยพอร์ตอัปสตรีมของฉัน _.

ในกรณีของฉันฉันมีการตั้งค่าเช่น

AWS ELB >> ECS(nginx) >> ECS(php-fpm).

ฉันกำหนดค่ากลุ่มความปลอดภัย AWS สำหรับบริการ ECS (php-fpm) ไม่ถูกต้องดังนั้น Nginx จึงไม่สามารถเข้าถึงคอนเทนเนอร์งาน php-fpm ได้ นั่นเป็นเหตุผลที่ฉันได้รับข้อผิดพลาดในบันทึกงาน nginx

499 0 - elb-healthchecker/2.0

การตรวจสุขภาพได้รับการกำหนดค่าเพื่อตรวจสอบบริการ php-fpm และยืนยันว่าพร้อมใช้งานและตอบกลับ