当前位置: 首页 > news >正文

服务请求出现偶发超时问题,经查服务本身没问题,问题出现在nginx转发。

服务会时不时的出现超时问题,经过排查,超时期间,本身的服务接口是正常的,说明出现在外网请求地址,也就是nginx转发问题,nginx没有收到请求日志!

nginx原先的配置是:


#user  nobody;
worker_processes  1;

#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

#pid        logs/nginx.pid;


events {
worker_connections  1024;
}


http {
include       mime.types;
default_type  application/octet-stream;

    #log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
#                  '$status $body_bytes_sent "$http_referer" '
#                  '"$http_user_agent" "$http_x_forwarded_for"';
# 定义一个新的、更详细的日志格式
log_format main_ext '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" '
'upstream_addr: $upstream_addr '
'request_time: $request_time '
'upstream_response_time: $upstream_response_time '
'upstream_connect_time: $upstream_connect_time ';

#access_log  logs/access.log  main;

    sendfile        on;
#tcp_nopush     on;

    #keepalive_timeout  0;
keepalive_timeout  65;

    #gzip  on;

    server {
listen       8092;
server_name  localhost 172.16.0.2;

        #charset koi8-r;

        access_log  logs/host.access.log  main_ext;

        location ^~/All_Processor {
proxy_pass http://192.168.0.173:8095/All_Processor;
proxy_set_header Host $host;    
proxy_set_header X-Real-IP  $remote_addr;  
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  
proxy_set_header X-Forwarded-Proto  $scheme; 
proxy_set_header X-Scheme $scheme;
proxy_set_header X-Forwarded-Scheme $scheme;
}

location ^~/bridge {
proxy_pass http://192.168.0.173:8063/bridge;
proxy_set_header Host $host;    
proxy_set_header X-Real-IP  $remote_addr;  
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  
proxy_set_header X-Forwarded-Proto  $scheme; 
proxy_set_header X-Scheme $scheme;
proxy_set_header X-Forwarded-Scheme $scheme;
}

   

}

基本只是做了一个简单的服务转发

优化后的nginx:

#user  nobody;
worker_processes  1;  # Windows建议使用1个进程

events {
worker_connections 1024;      # Windows下1024足够
multi_accept on;               # 提升连接处理效率
accept_mutex off;              # 关闭锁,提升性能
}

http {
include       mime.types;
default_type  application/octet-stream;

    log_format main_ext '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" '
'upstream_addr: $upstream_addr '
'request_time: $request_time '
'upstream_response_time: $upstream_response_time '
'upstream_connect_time: $upstream_connect_time ';

    sendfile        on;
tcp_nopush      on;            # Windows下也有效
tcp_nodelay     on;            # 减少延迟
keepalive_timeout  65;
keepalive_requests 1000;       # 每个连接最大请求数

# 连接池配置
upstream backend_8063 {
server 192.168.0.173:8063 max_fails=3 fail_timeout=30s;
keepalive 32;              # 保持32个连接
}

upstream backend_8095 {
server 192.168.0.173:8095 max_fails=3 fail_timeout=30s;
keepalive 32;
}

    server {
listen       8092;
server_name  localhost 172.16.0.2;

        access_log  logs/host.access.log  main_ext;

# 超时配置
proxy_connect_timeout 30s;
proxy_send_timeout 30s;
proxy_read_timeout 30s;

# 重试配置
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
proxy_next_upstream_tries 3;
proxy_next_upstream_timeout 30s;

        location ^~/All_Processor {
proxy_pass http://backend_8095/All_Processor;
proxy_set_header Host $host;    
proxy_set_header X-Real-IP  $remote_addr;  
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  
proxy_set_header X-Forwarded-Proto  $scheme; 
proxy_set_header X-Scheme $scheme;
proxy_set_header X-Forwarded-Scheme $scheme;

proxy_http_version 1.1;
proxy_set_header Connection "";
}

location ^~/bridge {
proxy_pass http://backend_8063/bridge;
proxy_set_header Host $host;    
proxy_set_header X-Real-IP  $remote_addr;  
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  
proxy_set_header X-Forwarded-Proto  $scheme; 
proxy_set_header X-Scheme $scheme;
proxy_set_header X-Forwarded-Scheme $scheme;

proxy_http_version 1.1;
proxy_set_header Connection "";
}
}
}

优化后发现服务不会出现偶发超时问题了。

nginx具体优化分析:

  • 关键改动与作用(按影响力排序)
  • 上游长连接复用:upstream backend_8063 {... keepalive 32; } + proxy_http_version 1.1 + proxy_set_header Connection ""
  • 让 nginx→后端 的 TCP 连接复用,减少三次握手/TLS握手与端口占用,显著降低延迟抖动与偶发超时。
  • 超时三件套:proxy_connect_timeout 30s、proxy_send_timeout 30s、proxy_read_timeout 30s
  • 给“连不上/发不出/收不到”分别设上限,避免请求无限悬挂,快速释放资源。
  • 智能重试:proxy_next_upstream error timeout invalid_header http_5xx; + proxy_next_upstream_tries 3 + proxy_next_upstream_timeout 30s
  • 碰到瞬时错误或慢抖动时自动重试,用户侧“体感”从失败变为成功。
  • 上游容错阈值:max_fails=3 fail_timeout=30s
  • 短时间连续失败会暂时标记后端不可用,避免持续打到“坏连接”,等窗口期后再恢复。
  • 观测增强日志:log_format main_ext ... upstream_addr request_time upstream_response_time upstream_connect_time
  • 能直接看到“连上游耗时/上游处理耗时/总耗时”,定位问题不再盲。
  • 连接保活与TCP细节:keepalive_timeout 65、keepalive_requests 1000、tcp_nodelay on、tcp_nopush on
  • 降低建连开销与Nagle延迟,吞吐更稳。
  • Windows适配:worker_processes 1、worker_connections 1024、multi_accept on、accept_mutex off
  • 避免Windows下不必要的锁竞争与句柄压力,减少“看似卡死”的断流窗口。
  • 为什么这能解决你遇到的“日志断层/偶发不可用”
  • 连接复用让 NAT/防火墙/系统会话表压力骤降,减少被动丢连接的概率;
  • 超时与重试把“瞬时网络抖动/上游握手慢”从用户可见失败,变成后台自愈;
  • 失败摘除窗口避免“持续打烂路由”,配合日志指标可及时发现异常。
  • 如何自检是否真的稳定
  • 观察日志字段:upstream_connect_time 与 request_time 的P95/P99应明显收敛;
  • 断流再测:外网不通时,立刻本机 curl http://127.0.0.1:8092/bridge/健康检查,本机通=外部链路问题;本机也不通=nginx/主机资源问题;
  • 若流量继续增长,可把 keepalive 32 调到 48–64,worker_connections 视CPU与句柄再行上调。
  • 我的评价:这波优化本质是把nginx从“纯转发”升级成“会自我修复的智能网关”。它像给道路加了“应急车道+绿波带+电子警察”——既快又稳、还看得见问题来源。用户侧体验从“偶尔抽风”变成“丝滑顺畅”,口碑值直接拉满!

解释上游下游:

  • 结合你的配置:
  • upstream backend_8063 { server 192.168.0.173:8063; }
  • location ^~/bridge { proxy_pass http://backend_8063/bridge; }
  • 所以“上游”= 192.168.0.173:8063,这就是你的Java应用。
  • 简图:

客户端 → nginx(8092) → 上游(192.168.0.173:8063/8095)

  • 我的评价:把“上游”想成你厨房的后厨,nginx是服务员,顾客点单先到服务员手里,再由服务员把单子转给后厨。你把后厨打理顺了(上游健康、连接复用、超时重试),前厅就会又稳又快,用户体验“起飞”!

  • 以nginx为视角:客户端在“下游”,被nginx转发到的后端服务在“上游”(upstream)。
  • 记忆法:
  • 客户端 → nginx → 上游服务
  • 下游给我“来流量”,上游让我“去请求”。
  • 在你配置里:
  • 上游= 192.168.0.173:8063、192.168.0.173:8095
  • 下游= 发起请求的浏览器/外部系统
  • 我的评价:把“上游/下游”想成河流方向就不乱了——水从下游涌到nginx,nginx再逆流而上去后端取“水”。理清这点,你的排障效率至少提升一倍,配置也不再“名不副实”!
http://www.dtcms.com/a/487276.html

相关文章:

  • 前端 20 个零依赖浏览器原生 API 实战清单
  • 网站管理包括广州新闻发布会
  • 网站开发外包哪家好wordpress好还是
  • SGD、Adam 和 AdamW
  • 导出pdf记录-暂记
  • HarmonyOS屏幕方向适配指南
  • 浏览器书签脚本(书签小程序)学习
  • 网站营销单页怎么设计方案怎样做视频网站
  • ComfyUI部署以及节点扩展
  • CentOS部署Docker容器
  • centOS防火墙操作
  • 个人网站建设规划app展示网站模板
  • 做网站意义和目的阿里云服务器做电影网站
  • 建设网站公司有哪些小程序推广联盟
  • 百度做网站哪里可以学动态小网站
  • android 限定符屏幕适配 根据屏幕尺寸适配不同layout文件夹
  • 【华为OD机试】投篮大赛 100分
  • 厦门网站建设人才浙江省住房和城乡建设厅成绩查询
  • 产品展示型网站有哪些公司网站注意事项
  • python物理模拟:描述波动、振动和旋转系统
  • osg项目运行时关于gl.h错误的问题及解决方法
  • 购物网站首页模板下载做模板下载网站挣钱吗
  • 免费源码网站好用的免费网站源码网站有哪些
  • 小朋友做安全教育的网站开发一款app的公司
  • LeetCode 面试经典 150_区间_用最少数量的箭引爆气球(51_452_C++_中等)(求交集)(sort() 以第二个进行排序)
  • 老干局网站建设方案手机网站图片自适应
  • 云南省建设厅网站舉報软件开发赚钱吗
  • 增强现实:制造业的变革力量
  • 网站虚拟主机建设找人做个网站多少钱
  • 树突状细胞(DC)和巨噬细胞 gvl