“connection refused”本质是服务端内核返回rst，表明ip:port可达但无应用监听或全连接队列满；error_log是定位“为何未监听/接不住”的线索入口，需结合nc、ss、netstat等系统命令验证。
“Connection refused”在 TCP 代理场景中，本质是客户端发出了 SYN 包，但服务端内核直接回了 RST（而非丢包或超时），说明目标 IP:Port 确实可达、路由通、防火墙放行，但**没有应用在监听该端口**，或**监听了却因队列满被内核静默丢弃**。error_log 本身不生成此错误（它是系统级 connect() 调用失败的 errno=111），但它能帮你定位“为什么没监听”或“为什么监听了却接不住”。关键在于：error_log 是线索入口，不是直接答案。
确认 error_log 是否真包含相关上下文
很多代理（如 Nginx、HAProxy、squid）在连接上游失败时，会在 error_log 中记录带 upstream、proxy_pass 或 backend 关键字的明确错误行，例如：
- Nginx：
upstream connection refused while connecting to upstream - HAProxy：
Connect() failed for server srv1: Connection refused - 自研代理若用日志框架打印异常栈，可能含
java.net.ConnectException: Connection refused
若 error_log 完全无此类记录，说明问题发生在代理进程自身启动前（比如 systemd 启动失败）、或代理根本未尝试发起连接（DNS 解析失败、配置未加载、路由策略跳过代理逻辑）。此时 error_log 价值有限，需转向系统日志（journalctl -u xxx）或启动输出。
从 error_log 错误行反推代理行为路径
拿到一条典型的 error_log 报错后，重点看三个字段：
- 上游地址（IP 和端口）：是否写死？是否来自 DNS 动态解析？是否用了变量（如 $upstream_addr）？若显示 127.0.0.1:8080，要立刻检查该服务是否只绑定了 127.0.0.1（无法被外部代理访问）
- 时间戳与频率：是偶发单条，还是秒级爆发？若突增且伴随“queue overflowed”类指标上升，指向全连接队列满；若稳定出现，更可能是服务未启动或端口错配
- 关联请求 ID 或 client IP：结合 access_log 追踪同一请求的完整链路，确认是所有客户端都失败（服务端问题），还是仅特定 client 失败（客户端网络或代理路由规则问题）
用 error_log 触发系统级验证动作
error_log 的价值在于驱动下一步精准验证，而非止步于日志文本：
- 若日志指出 upstream 为
10.1.2.3:3000，立即执行：nc -zv 10.1.2.3 3000—— 验证基础连通性与端口开放ss -tlnp | grep :3000—— 查看是否有进程监听，且 Listen 地址是否为*:3000或0.0.0.0:3000（非 127.0.0.1） - 若日志中 upstream 是域名（如
api.internal:8443），先查 DNS：nslookup api.internal或dig +short api.internal，再对解析出的每个 IP 执行 nc 测试 - 若日志显示大量失败且时间集中，同步查队列溢出：
netstat -s | grep -i "listen.*overflow"或ss -lnt | awk '$2 > $3 {print "ALERT: queue full on", $4}'
关联 error_log 与内核参数和资源瓶颈
当 error_log 显示“connection refused”呈周期性或负载升高时加剧，需检查：
-
somaxconn 值：
cat /proc/sys/net/core/somaxconn，若仍为默认 128，高并发代理场景极易打满全连接队列 -
文件描述符限制：代理进程 ulimit -n 是否足够？
lsof -p $(pgrep nginx) | wc -l对比上限值 -
TIME_WAIT 占用：大量短连接可能导致端口耗尽，
netstat -an | grep TIME_WAIT | wc -l若超万级，需调优net.ipv4.tcp_tw_reuse
这些参数本身不会写入 error_log，但它们是 error_log 中高频“connection refused”的幕后推手。
