抓包是第一步
排查网络问题，很多人第一反应就是抓包。比如你家Wi-Fi看着连上了，网页打不开，视频卡成幻灯片，这时候就得看看设备到底发了啥、收了啥。常用的工具像Wireshark，装上就能监听网卡上的所有流量，把一个个数据包展示出来，像TCP三次握手、DNS查询这些过程都能看得清清楚楚。
实际操作中，你可以设置过滤条件，只看HTTP或者某个IP的通信，避免信息太多眼花。比如公司内网某台机器连不上服务器，抓包发现根本没发出SYN包，那问题可能出在本地防火墙或者路由配置。
用命令行快速诊断
不是每次都要开图形界面抓包。日常排错，ping和traceroute（Windows下叫tracert）最常用。ping能测通不通，延迟高不高；traceroute能看出数据包经过哪些节点，在哪一跳开始丢包。比如访问某个网站特别慢，traceroute发现是在运营商骨干网某段延迟飙升，那就不是你本地的问题了。
另外netstat也能帮上忙，查本机有哪些连接在跑，处于什么状态。要是发现一堆连接卡在SYN_SENT，多半是出站被拦了，或者是目标服务压根没响应。
深入看协议交互细节
有些问题是表面看不出的。比如APP登录总失败，但网络明明通。这时候得看应用层协议。用Wireshark打开抓包文件，找HTTP请求，看看是不是返回了401或者302重定向去了奇怪的地方。也可能是TLS握手失败，客户端和服务器支持的加密套件对不上。
举个例子，某次调试发现手机APP发出去的POST请求，Content-Type写成了text/plain，但服务器只认application/json，结果一直报参数错误。这种问题不看协议载荷根本发现不了。
模拟请求辅助验证
除了被动抓包，主动发请求也能验证猜想。比如用curl命令手动构造一个HTTP请求：
curl -v http://api.example.com/user -H "Authorization: Bearer abc123"加上-v参数能看到完整的请求头和响应过程。如果这个能通，但APP不行，那问题就锁定在APP本身的网络模块。
再复杂点的情况，可以用Python的socket库写个小脚本，模拟TCP连接，一步步发特定字节流，测试服务端的行为。这种办法在对接硬件设备时特别实用，很多嵌入式系统通信协议不标准，只能靠手动拼数据包来试。
关注时间线和重传
网络抖动时，重传率是个关键指标。Wireshark里看到大量TCP Retransmission，说明链路不稳定或者中间设备过载。结合时间戳看，如果每次重传都发生在固定间隔（比如1秒后），那可能是中间有NAT超时限制。
还有种情况是乱序到达（Out-of-Order），Wireshark会标出来。轻微乱序通常不影响，但如果频繁出现，可能导致TCP反复触发快速重传，吞吐量直接掉一半。这种情况多见于多路径负载均衡策略不合理，或者Wi-Fi信号忽强忽弱。