反向代理 27833 recv() failed (104: Connection reset by peer) while reading response header from upstream错误

原因就是请求的头文件过大导致502错误

解决方法就是提高头的缓存

http{

client_header_buffer_size 5m;

location / {

proxy_buffer_size 128k;
proxy_busy_buffers_size 192k;
proxy_buffers 4 192k;

}

原文地址：https://www.cnblogs.com/chenkg/p/8364579.html

时间： 2024-10-25 06:08:39

反向代理 27833 recv() failed (104: Connection reset by peer) while reading response header from upstream错误的相关文章

recv() failed (104: Connection reset by peer) while reading response header from upstream

场景: 为了得到用户在线等信息,在客户端做了个ajax轮训: 于是问题就来了, 日志文件 [[email protected] web]# tail -f /data/log/nginx_error.log 2017/06/16 19:20:28 [error] 230555#0: *10228041 recv() failed (104: Connection reset by peer) while reading response header from upstream,client:

nginx错误分析 `104: Connection reset by peer`

故障描述应用从虚拟机环境迁移到kubernetes环境中,有些应用不定时出现请求失败的情况,且应用没有记录任何日志,而在NGINX中记录502错误.我们查看了之前虚拟机中的访问情况,没有发现该问题. 基础信息 # 请求流程 client --> nginx(nginx-ingress-controller) --> tomcat(容器) # nginx版本 $ nginx -V nginx version: nginx/1.15.5 built by gcc 8.2.0 (Debian 8.

Nginx" upstream prematurely closed connection while reading response header from upstream"问题排查

问题背景我们这边是一个基于Nginx的API网关(以下标记为A),最近两天有调用方反馈,偶尔会出现502错误,我们从Nginx的error日志里看,就会发现有" upstream prematurely closed connection while reading response header from upstream"这么一条错误日志,翻译过来其实就是上游服务过早的关闭了连接,意思很清楚,但是为什么会出现这种情况呢.而且是在业务低峰出现这种情况(也只是小概率的出现),在业务高

OGG-01232 Receive TCP params error: TCP/IP error 104 (Connection reset by peer), endpoint:

源端: 2015-02-05 17:45:49 INFO OGG-01815 Virtual Memory Facilities for: COM anon alloc: mmap(MAP_ANON) anon free: munmap file alloc: mmap(MAP_SHARED) file free: munmap target directories: /home/ggt/goldengate/dirtmp. CACHEMGR virtual memory values (may

java.net.SocketException: recvfrom failed: ECONNRESET (Connection reset by peer)

java.net.SocketException: recvfrom failed: ECONNRESET (Connection reset by peer)11-22 14:49:16.870: WARN/System.err(3581): at libcore.io.IoBridge.maybeThrowAfterRecvfrom(IoBridge.java:542)11-22 14:49:16.870: WARN/System.err(3581): at libcore.

OGG-01232 Receive TCP Params Error: TCP/IP Error 104 (Connection Reset By Peer).

经常在OGG日志文件中看到如下错误: 查了metalink,大概说的是extract 和collector 交互的关系,分为STREAMING 和NOSTREAMING 模式,各有各的优势.总的建议如果该错误不是很频繁,建议使用STREAMING模式.下面贴出原文: OGG-01232 Receive TCP Params Error: TCP/IP Error 104 (Connection Reset By Peer). (文档 ID 1684527.1) 转到底部 In this Docu

LR回放https协议脚本失败：[GENERAL_MSG_CAT_SSL_ERROR]connect to host "XXX" failed:[10054] Connection reset by peer [MsgId:MERR-27780]

最近做一个负载均衡项目的性能测试,使用LR录制脚本协议为https协议,回放脚本时出现报错: [GENERAL_MSG_CAT_SSL_ERROR]connect to host "XXX" failed:[10054] Connection reset by peer [MsgId:MERR-27780] 如图: Loadrunner默认发送是通过sockets(将http转换为sockets)发送的,而sockets默认SSL的版本为SSL2和SSL3.HTTPS协议录制的脚本以

nginx error: upstream prematurely closed connection while reading response header from upstream

本篇文章由:http://xinpure.com/nginx-error-upstream-prematurely-closed-connection-while-reading-response-header-from-upstream/ 环境描述 Nginx 版本 1.10.2 PHP 版本 7.0.12 Node 版本 5.9.0 本文是想讲一个 Nginx 的错误,为啥还要提及 PHP 和 Node 的版本呢?容我先还原一下应用场景首先就是我有一个绑定在 3000 端口的 Node S

xdebug 一直报错 upstream timed out (110: Connection timed out) while reading response header from upstream

本地主机(Windows环境192.168.66.1)访问虚拟机(192.168.66.139)里面的搭建的php环境(系统centos6.5版本,php版本是5.5.30 ,xdebug 2.4.0),通过命令行pecl install xdebug安装的xdebug, 在php.ini配置xdebug [Xdebug]zend_extension=/usr/local/php/lib/php/extensions/no-debug-non-zts-20121212/xdebug.soxdeb