Nginx报错104:
错误日志里面出现大量的104: Connection reset by peer) while reading upstream是怎么回事，怎么处理？ 104: Connection reset by peer 是一个常见的网络错误，它表示在数据传输过程中，连接被对方重置。在 Web 服务器（如 Nginx）的上下文中，这通常意味着后端服务（如应用服务器或数据库服务器）在 Nginx 试图读取其响应时，意外地关闭了连接。这个问题可能由多种原因引起，以下是一些可能的原因和相应的解决方案：后端服务超时：
检查后端服务的超时设置，确保它们足够长，以便处理请求并返回响应。
[*]如果可能，优化后端服务的性能，以减少处理时间。
资源限制：
检查后端服务是否有足够的资源（如内存、CPU）来处理请求。
[*]监控后端服务的性能指标，确保它们没有达到瓶颈。
网络问题：
检查网络连接是否稳定，确保没有网络中断或丢包现象。
[*]如果后端服务是远程的，确保网络连接足够稳定以支持数据传输。
Nginx 配置问题：
检查 Nginx 的配置，特别是与后端服务通信的部分。
[*]调整 Nginx 的超时设置，如 proxy_connect_timeout、proxy_send_timeout、proxy_read_timeout 等，以确保它们与后端服务的预期响应时间相匹配。
后端服务崩溃或被重启：
检查后端服务的日志，查看是否有异常崩溃或重启的记录。
[*]如果是由于代码错误导致的崩溃，需要修复相应的 bug。
并发连接数过高：
如果后端服务无法处理过多的并发连接，可能需要增加资源或优化代码以处理更高的并发量。
[*]在 Nginx 中配置适当的并发连接限制，以防止过多的请求同时到达后端服务。
防火墙或安全策略限制：
检查是否有任何防火墙或安全策略在特定条件下重置连接。
[*]与网络管理员或 IT 支持团队联系，了解是否有任何可能影响连接的网络策略。
处理这个问题时，建议从以下几个方面入手：
分析日志：仔细检查 Nginx 和后端服务的日志，以找出连接被重置的具体原因。监控性能：使用性能监控工具来跟踪后端服务的性能指标，如 CPU 使用率、内存使用率等。调整配置：根据分析结果调整 Nginx 和后端服务的配置，以优化性能和稳定性。测试：在进行任何更改后，都要进行充分的测试，以确保问题已得到解决且没有引入新的问题。
如果以上方法都不能解决问题，可能需要更深入地调查网络层面的问题，或者考虑与专业的 IT 支持团队合作来诊断和解决根本原因。 作为DZ插件网技术团队成员，关于Nginx报错104（Connection reset by peer）的排查与解决方案如下：
**一、问题本质分析**
该错误表明客户端在Nginx与上游服务（如PHP-FPM）通信时异常断开连接，通常发生在：
1. 上游服务处理超时主动断开
2. 客户端提前终止请求（关闭浏览器/网络波动）
3. 服务器间TCP连接异常中断
**二、Discuz专项排查要点**
1. **耗时插件检测**
检查近期安装的插件是否包含以下特征：
- 未使用分页查询的大数据量操作
- 未正确关闭的数据库连接（show processlist查看）
- 未使用ob_clean()的循环输出
推荐通过DZ插件网的性能检测工具分析插件效率
2. **PHP-FPM优化方案**
; php-fpm.conf优化项
request_terminate_timeout = 300s ; 与Nginx超时保持同步
pm.max_children = 100 ; 根据内存调整（每个进程约30-50MB）
pm.start_servers = 20
pm.min_spare_servers = 10
pm.max_spare_servers = 30
3. **Nginx核心配置调整**
location ~ [^/]\.php(/|$) {
fastcgi_read_timeout 300s; # 建议保持与PHP超时一致
fastcgi_send_timeout 180s;
fastcgi_connect_timeout 75s;
fastcgi_buffer_size 128k;
fastcgi_buffers 256 16k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
}
**三、Discuz深度优化方案**
1. 数据库优化
# 检查慢查询（需配置my.cnf）
slow_query_log = 1
long_query_time = 1
log_queries_not_using_indexes = 1
# 常用优化语句
ALTER TABLE pre_forum_post ENGINE=InnoDB;
ANALYZE TABLE pre_forum_thread;
OPTIMIZE TABLE pre_common_session;
2. 文件缓存优化
修改config/config_global.php：
$_config['memory']['prefix'] = 'dz_';
$_config['cache']['type'] = 'redis'; // 建议使用内存缓存
$_config['output']['gzip'] = 1; // 开启GZIP压缩
**四、网络层排查**
1. 使用TCP重传检测：
netstat -s | grep -E 'retransmits|resets'
ss -neopt state established | wc -l
2. 内核参数优化（/etc/sysctl.conf）：
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_tw_reuse = 1
net.core.somaxconn = 65535
**五、压力测试验证**
使用wrk进行负载测试：
wrk -t12 -c400 -d30s --latency http://your_domain/forum.php
建议按照以下顺序排查：
1. 检查PHP错误日志（注意@抑制错误）
2. 分析MySQL慢查询日志
3. 使用strace追踪PHP-FPM进程
4. 通过DZ插件网的性能分析工具检测插件
若需进一步诊断，可提供以下信息：
1. Nginx access_log片段（含upstream_response_time）
2. PHP-FPM slowlog记录
3. MySQL SHOW ENGINE INNODB STATUS输出
附：Discuz性能优化白皮书可在DZ插件网技术文档板块获取，包含200+项深度优化方案。
-- 本回答由 人工智能 AI智能体 生成，内容仅供参考，请仔细甄别。
页:
[1]