テクノロジー · 実用ガイド
NGINX の「upstream sent too big header」？buffer を増やす前に protocol と header owner を特定する
proxy、FastCGI、uWSGI のどれかを証明し、response header を測定し、暴走 cookie を減らしてから該当 first buffer だけを調整します。
この error は upstream response header の境界であり、upload body や client request-header limit ではありません。すべての buffer を増やす根拠にもなりません。
一つの失敗 request、effective location、module、header bytes を保存し、異常 field を減らします。正当な上限だけを最小 context で調整します。
失敗 request と effective route を保存
NGINX の完全な error 行、timestamp、request ID、host、URI、status、upstream address、worker PID を保存します。Cookie の値などの秘密は記録せず、access log、upstream application log、authentication log を相関させます。
実際に稼働している同じ image または host で nginx -T を実行し、include 展開後の server と location を保存します。master PID、config path、deployment revision を記録し、worker が読み込んでいない file の編集を修正扱いしません。
directive 前に upstream protocol を特定
この error は upstream が返した response に関するものです。proxy_pass なら proxy_buffer_size、fastcgi_pass と uwsgi_pass なら各 module の directive family を確認します。client_max_body_size と large_client_header_buffers は別の request-side boundary です。
一般的な snippet ではなく、error log の upstream scheme と effective location から directive を選びます。FastCGI や uWSGI の request に proxy_* は作用せず、global な増量は全 route の memory を無駄に増やす可能性があります。
response-header owner を測定
安全な環境または direct upstream path で、同じ authentication と session state を再現します。値を redact しながら header 名と byte length を取り、重複 Set-Cookie、Location、authentication metadata、custom field を重点確認します。
成功 response と失敗 response を比較し、単一 field が first-response buffer を超えたのか、複数 field が累積したのかを分けます。session、OAuth state、serialized application data が原因なら、可能な限り producer 側で削減します。
最小の module-specific 変更を適用
重複または過大な Cookie を減らし、大きな session state は server side に移し、不要な metadata を除去して redirect/auth state を制限します。正当な header が残る場合だけ、最小の effective context で対応 module buffer を上げます。
proxy buffering を変える場合は proxy_buffers と busy-buffer constraint を保ちますが、first response header の測定の代用にはしません。syntax check、graceful reload、running worker が展開済み config を継承したことまで確認します。
同じ state を再実行し memory を確認
同じ URI、method、upstream、authentication callback、session size を replay します。502 が消え、error log が clean で application result が正しいことを確認し、near-limit と over-limit case も試します。
旧新 directive、effective location、header-byte summary、worker reload time、request ID、concurrency、memory impact、rollback threshold を記録します。login や cart expansion 後も監視し、新 buffer が無界な producer bug を先送りしていないことを確認します。
