Java网络异常排查需分层定位：先验证网络连通性（ping、telnet、nslookup），再检查服务状态与资源（进程、端口、日志、系统资源），接着分析TCP行为（Connection refused/reset等），最后审查客户端代码与配置（超时、连接池、流关闭、重试）。
Java网络异常排查不是靠猜，而是按层次快速定位：先看连不连得上，再看通不通得了，最后看稳不稳定。核心是分清问题发生在哪一层——网络层、传输层、应用层，每层对应不同的工具和思路。
网络连通性验证（最外层）
这是第一步，也是最容易被跳过的一步。很多问题其实卡在根本没通网。
- 用 ping 测试目标IP是否可达（注意：有些服务器禁ping，不能单凭这个下结论）
- 用 telnet IP 端口 或 nc -vz IP 端口 验证端口是否开放、服务是否监听
- 如果域名访问失败，立刻试 nslookup 域名 或 dig 域名，确认DNS解析是否正常；再直接换IP重试，排除DNS干扰
服务端状态与资源检查（中间层）
连得上≠服务能响应。常见问题是服务活着但“瘫着”。
- 查进程：用 ps -ef | grep java 确认服务进程还在运行
- 查端口：用 netstat -tuln | grep :端口号 或 lsof -i :端口 看端口是否真被监听
- 查日志：重点看启动日志（如catalina.out）、最近ERROR/WARN行，留意 OutOfMemoryError、Too many open files、线程池拒绝等线索
- 查资源：用 top、free -h、df -h 快速扫CPU、内存、磁盘；用 cat /proc/sys/fs/file-nr 查文件描述符使用量
TCP连接行为分析（传输层）
当出现 Connection reset、Connection refused、NoRouteToHost 等异常时，需要深入协议交互细节。
立即学习“Java免费学习笔记（深入）”；
- Connection refused：90%是服务没启、端口错、防火墙拦住——先做上一步的 telnet 测试
- Connection reset by peer：服务端已发RST包，常见于服务崩溃重启、主动kill连接、或设置了过短的 keepalive 时间
- NoRouteToHost / Host unreachable：路由表缺失或网关不通，用 ip route get 目标IP 和 arp -a 辅助判断
- 抓包辅助：用 tcpdump -i any host 目标IP and port 端口 -w conn.pcap 抓包，Wireshark里看SYN是否发出、是否有SYN-ACK返回、是否收到RST
客户端代码与配置审查（应用层）
很多异常表面是网络问题，根源在代码写法或参数不合理。
- 检查超时设置：connectTimeout（建连时间）建议设为3–10秒，socketTimeout（读取等待）应略大于业务P99耗时
- 确认是否用了连接池（如Apache HttpClient Pool、HikariCP），并检查 maxIdle、maxLifeTime 是否合理，避免连接复用失效
- 查看是否漏关流：用 try-with-resources 包裹 Socket、InputStream、OutputStream，防止连接泄漏
- 有重试逻辑？需带退避（如指数退避），避免雪崩；无重试？至少加一层基础 fallback 或降级响应
基本上就这些。从外到内、由简入繁，一次聚焦一个层面，多数Java网络异常3分钟内就能圈定范围。不复杂但容易忽略——尤其是忘了先 telnet 一下。
