超时是症状不是根因
通信超时指请求方在约定时间内没收到完整响应而主动放弃。它只是症状，根因可能落在对端设备、中间网络、协议参数或请求方自身。工控现场的典型表现是 HMI 数据点变灰、SCADA 报通信中断、控制器与远程 IO 掉站。排查的关键动作是把模糊的“超时”拆成可测量的分段时间：连接建立、请求发出、对端处理、响应返回。
基本信息
| 现象分类 | 连接超时（建不了链）、读超时（无响应）、写超时（无确认） |
|---|---|
| 相关参数 | 连接超时、响应超时、重试次数与重试间隔 |
| 可能层次 | 应用层协议、传输层、链路层、设备处理能力 |
| 首要判据 | 超时是否规律、是否集中在某设备某时段某类操作 |
典型使用场景
- 单个数据点频繁超时而其他点正常，怀疑点表地址或设备响应策略时
- 多台设备同时超时，需要判断是共同链路还是共同上游问题时
- 超时集中在特定时段，怀疑与负荷启停或外部干扰相关时
- 新增或改造后出现超时，核对超时参数与轮询周期是否匹配时
- 需要向厂家提交可复现证据，而不是只说一句“它不稳定”时
根因分层对照
| 层次 | 典型根因 | 快速验证 |
|---|---|---|
| 请求方 | 轮询周期过短、并发过高、采集进程阻塞 | 看请求发送间隔与主机 CPU 占用 |
| 网络 | 丢包抖动、环路、未配优先级、跨网段路由异常 | 逐跳丢包检测与端口错误计数 |
| 对端设备 | 响应慢、接收缓冲区满、连接数上限、固件缺陷 | 直连或旁路复测同一请求 |
| 协议与配置 | 超时阈值过小、重试策略不当、站号或地址填错 | 对照点表与设备参数文档逐项核对 |
分段计时验证
分段计时验证
timeout 5 nc -vz 192.168.1.10 502 # 先确认 TCP 端口能否建立连接
time curl -s -o /dev/null -w 'connect=%{time_connect} total=%{time_total}\n' http://192.168.1.10/
ping -c 20 192.168.1.10 # 链路层是否稳定
# 周期探测并记录超时发生的时刻，便于和外部事件对齐
for i in $(seq 1 30); do printf '%s ' "$(date +%T)"; timeout 1 bash -c 'echo > /dev/tcp/192.168.1.10/502' && echo ok || echo timeout; done
tcpdump -i eth0 -nn host 192.168.1.10 -w timeout.pcap # 抓包看请求与响应的时间差超时阈值必须大于最坏情况下的响应时间（含重传与队列排队）。先实测响应时间的高分位数再定阈值，否则正常波动就会触发报警，值班人员会逐渐忽略真正的故障。
Modbus 这类单主站协议有一个放大效应：点表里某个站号填错或设备已下线，主站会一直等到该站超时，表现为“所有点都变慢”。看到全线变慢先怀疑一个不存在的站。
不要用调超时参数来消警：把阈值调小只会制造更多报警，调大只是掩盖问题，根因仍在网络上或设备侧，计划窗口前应先恢复正确参数。