Nginx uwsgi (104: Connection reset by peer) 同時從上游讀取響應頭

Question

環境是Nginx + uwsgi。

在某些 GET 請求上從 Nginx 獲取 502 bad gateway 錯誤。 好像跟網址的長度有關。 在我們的特殊情況下，它是一長串 GET 參數。 縮短GET參數，沒有502錯誤。

從 nginx/error.log

[error] 22113#0: *1 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.1.100, server: server.domain.com, request: "GET <long_url_here>"

uwsgi 錯誤日志中沒有信息。

Answer 1

在花了很多時間之后，我終於弄明白了。 有很多對 Nginx 和對等連接重置的參考。 他們中的大多數似乎都與 PHP 相關。 我找不到特定於 Nginx 和 uwsgi 的答案。

我終於找到了對 fastcgi 的引用和 502 bad gateway 錯誤（ https://support.plesk.com/hc/en-us/articles/213903705 ）。 這導致我在 uwsgi 配置中尋找緩沖區大小限制，該限制作為buffer-size存在。 默認值為 4096。從文檔中，它說：

如果您計划接收帶有大量標頭的大型請求，您可以將此值增加到 64k (65535)。

配置uwsgi的方法有很多，我正好用了一個.ini文件。 所以在我的 .ini 文件中我試過：

buffer-size=65535

這解決了問題。 你可以根據口味調整它。 也許從最大值開始並返回，直到獲得可接受的值，或者將其保留在最大值。

這令人沮喪，因為在 uwsgi 方面沒有錯誤。

Answer 2

我收到了同樣的 nginx 錯誤，而且 uwsgi 日志中也沒有信息。 問題是，在某些情況下，應用程序沒有按照http://uwsgi-docs.readthedocs.org/en/latest/ThingsToKnow.html 中的建議使用整個請求正文：

如果 HTTP 請求有正文（如表單生成的 POST 請求），則必須在應用程序中讀取（使用）它。 如果您不這樣做，與您的網絡服務器的通信套接字可能會被破壞。 如果你很懶惰，你可以使用后緩沖選項，它會自動為你讀取數據。 對於機架應用程序，這是自動啟用的。

當然，這在您的情況下不是問題，但對於遇到相同 nginx 錯誤的其他人來說可能有用。

Answer 3

我們只需要將 php.ini 中的屬性“output_buffering”值增加到更大的值，例如 65535 或其他合適的值。

Answer 4

當我們(104: Connection reset by peer) while reading response header from upstream時收到類似(104: Connection reset by peer) while reading response header from upstream ，大多數情況下，我們可以將這種錯誤歸咎於上游。

如上所述，連接是由上游對等方重置的，而不是由 nginx 本身重置的。 Nginx 作為客戶端幾乎無法做任何事情來使它正確。

我懷疑修改緩沖區大小是否會起作用。 基本上，該命令會更改緩存響應標頭的緩沖區大小。 這會在響應頭太大時生效，在這種情況下，我們upstream sent too big header while reading response header from upstream收到一條消息說upstream sent too big header while reading response header from upstream ，這與connection reset by peer完全不同。

由於這種錯誤是隨機觸發的，我建議您在與上游對話時檢查nginx是否使用keepalive 。 如果是這種情況，當空閑超時時上游服務器可能會重置連接，而 nginx 不知道連接已斷開，因此使用相同的連接轉發請求。

據我所知，沒有優雅的解決方案來修復它。 您可以重試或為 nginx 中的上游連接池設置keepalive_timeout值以避免該問題。

參考：

Apache HttpClient 臨時錯誤：NoHttpResponseException

http://tengine.taobao.org/document/http_upstream_keepalive_timeout.html

Answer 5

--post-buffering 32768按照建議（和不鼓勵）在此處NGINX + uWSGI Connection Reset by Peer為我工作

我目前沒有時間進一步研究它（快速原型模式:)，但由於我花了很多時間來找到這個 hack，所以可能值得在這里發布。

Answer 6

它不會偶爾出現。

我想最可能的原因是你的php-fpm.log的大小過大。 嘗試在php-fpm.conf log_level更改為上層並清除日志。

無論如何，它對我有用。

Answer 7

如果您的請求/響應標頭非常大，就會發生這種情況。

要修復它，在/etc/uwsgi/apps-available/your-app.ini添加buffer-size=65535

Answer 8

您需要重新安裝 PHP：

apt-get install --reinstall php5-fpm