一、故障现象：客户端卡在 20%，换手机网络却能正常进入
某企业客户使用 Windows 端"社保费管理客户端"，启动后在"同步系统配置信息"阶段进度约 20% 时失败，提示"获取接收配置失败，请检查网络设置"。
二、排查原则：先做最基础的排查来定域，再深挖，不要一上来重装客户端
| 问题 | 结果 |
|---|---|
| 切换手机热点能不能正常使用 | 切换热点后恢复正常 |
| 其他同网络环境下电脑是否可以正常使用 | 其他同网络电脑正常 |
通过基础排查，基本上确认是网络相关问题，电脑本身系统、软件是正常的；但是很奇怪的是，另外同网络下的其他电脑又是正常的。
三、第一步：确认基础网络配置没有明显差异
先对故障机与同网络正常机做最基本的 A/B，对比 ipconfig /all 与 route print -4。两台机器的 DHCP、子网、默认网关和 DNS 口径一致，故障机也没有额外的永久路由或 VPN 默认路由。
随后检查 WinHTTP / WinINET 代理与 PAC：
netsh winhttp show proxy
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyServer
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v AutoConfigURL
WinHTTP 为直接访问，WinINET 代理未启用，未发现 PAC 地址。代理配置因此降为低概率。
到这里，继续反复执行 ipconfig /flushdns、重装客户端、重置 Winsock 的信息增益已经很低。下一步应该直接观察客户端到底在访问谁。
四、第二步：抓"真正失败的目标"，不要只验证"能不能上网"
使用 Windows 自带 pktmon 在 NIC 层抓取一次完整失败过程：
mkdir C:\EPTrace
pktmon stop
pktmon filter remove
pktmon start --capture --comp nics --pkt-size 0 --file-name C:\EPTrace\BAD.etl --file-size 128 --log-mode circular
# 复现客户端故障后
pktmon stop
pktmon etl2pcap C:\EPTrace\BAD.etl --out C:\EPTrace\BAD.pcapng
pktmon etl2txt C:\EPTrace\BAD.etl --out C:\EPTrace\BAD.txt --brief抓包里有两个非常关键的对照：
- 故障机访问另一个公网 HTTPS 目标
47.96.150.253:443时，TCP 可以建立并有双向数据传输。 - 客户端随后访问湖北税务业务目标
etax.hubei.chinatax.gov.cn → 220.249.78.153:443时，连续发送 SYN，但没有收到对应的 SYN-ACK 或 RST。
| 时间 | 方向 | 抓包现象 |
|---|---|---|
| 11:53:05.236 | 企业终端 → 220.249.78.153:443 | SYN |
| 11:53:06.294 | 企业终端 → 220.249.78.153:443 | SYN 重传 |
| 11:53:08.298 | 企业终端 → 220.249.78.153:443 | SYN 重传 |
| 11:53:12.311 | 企业终端 → 220.249.78.153:443 | SYN 重传 |
| 11:53:20.314 | 企业终端 → 220.249.78.153:443 | SYN 重传 |
上表从原始 PktMon 文本中提取，终端内网地址和 MAC 已脱敏。连续重传间隔逐步增长，符合 TCP 建连超时的典型表现。
五、第三步：用 Test-NetConnection 把"Ping 通但业务不通"说清楚
随后直接对业务目标做 TCP 443 端口测试，并同时用另一个正常 HTTPS 目标做正向对照：
Test-NetConnection etax.hubei.chinatax.gov.cn -Port 443 -InformationLevel Detailed
Test-NetConnection live.shuiyou.com.cn -Port 443 -InformationLevel Detailed
公司有线网络下：业务目标 DNS 解析成功、Ping 成功，但 TCP/443 失败；另一个 HTTPS 目标正常。
**不要把"Ping 通"理解成"网络没问题"。**Ping 使用 ICMP，而客户端依赖的是 TCP/443。ICMP 可达只能说明目标在三层上存在可达性，不能证明业务端口、ACL、NAT、安全策略或返回路径正常。
六、第四步：同一台电脑切手机网络------建立最强 A/B
把同一台电脑切换到 USB 手机共享网络，再对同一个域名、同一个公网 IP、同一个 TCP/443 测试：
同一台电脑、同一业务域名、同一公网目标：切换手机网络后 TCP/443 成功。
把故障范围压缩到企业有线接入这一条路径及其相关终端身份。
七、第五步：验证是否只是原来的源 IP 被限制
如果现场条件允许且明确知道某个地址当前没有被其他设备占用，可以做一次受控的源 IP A/B。本案例中，先让正常终端断网，再临时把故障机配置为该正常终端原使用的地址进行测试。
更换为另一可用终端的地址后，目标 TCP/443 仍失败，因此"原源 IP 单独被限制"的可能性明显下降。
**注意：**不要在生产网络里随便猜一个静态 IP。若无法确保地址空闲，跳过这一步，直接由网络人员从 DHCP、NAC、防火墙或交换机侧做 A/B 更安全。
八、第六步：把本机网络过滤和防火墙再降一级
继续检查有线网卡绑定，未看到明显第三方 VPN、杀软、准入或流量控制类 NDIS Filter；Windows 防火墙也没有查到启用的显式出站 Block 规则：
Get-NetAdapterBinding -Name "以太网 5" |
Where-Object Enabled |
Format-Table DisplayName,ComponentID -AutoSize
Get-NetFirewallRule -Enabled True -Direction Outbound -Action Block
Get-NetFirewallProfile |
Select-Object Name,Enabled,DefaultInboundAction,DefaultOutboundAction
网卡绑定未见明显第三方过滤组件；防火墙默认出站未显式配置为 Block。
这里要注意证据强弱：DefaultOutboundAction = NotConfigured 本身不能单独证明"绝对不会被拦"，但结合前面的 NIC 层抓包已经看到 SYN 确实发出，本机在发送前阻断该连接的概率已经很低。
九、最终定域：可以转网络侧，但不知道是哪个策略导致
| 证据等级 | 结论 |
|---|---|
| 已确认 | 业务域名可以正常解析到公网目标；公司有线下该目标 Ping 可达，但 TCP/443 建连失败。 |
| 已确认 | NIC 层抓包看到 SYN 从终端发出并多次重传，未见对应 SYN-ACK / RST。 |
| 已确认 | 同一终端切 USB 手机网络后，对同一公网目标 TCP/443 成功，客户端可正常使用。 |
| 已确认 | 更换终端源 IP 后仍失败，原 IP 被单独限制的可能性明显降低。 |
| 高概率 | 故障位于企业有线网络路径、终端准入/身份、ACL、防火墙、上网行为管理、安全网关、NAT/session 或返回路径中的某一环节。 |
| 待验证 | 具体是哪台网络设备、哪条规则或哪项配置导致。 |
最终客户确认网络人员已处理恢复。由于没有拿到网络侧具体改动，不确认最终根因，只提供分析思路给大家参考。
十、给网络人员同步什么，才能让对方直接开始查
把"网络有问题"四个字丢给网管几乎没有排查价值。一个合格的交接至少应该包含下面这些字段：
终端：某企业故障终端
源 IP：172.16.0.X（已脱敏）
源 MAC：48-F3-17-XX-XX-XX（已脱敏）
目标域名：etax.hubei.chinatax.gov.cn
目标 IP：220.249.78.153
目标端口：TCP/443
故障时间：约 11:53 起多次复现
现象：
1. DNS 正常解析；
2. ICMP Ping 成功；
3. TCP/443 失败；
4. PktMon 在物理网卡侧看到 SYN 已发出，多次重传，无 SYN-ACK/RST；
5. 同机走手机 USB 网络，同一目标 TCP/443 成功；
6. 临时更换源 IP 后仍失败；
7. 另一个公网 HTTPS 目标在公司有线下正常。
请网络侧重点检查：
- 防火墙 / ACL deny、drop、reset 日志
- NAC / 准入 / 终端身份策略
- 上网行为管理 / URL 分类 / IPS
- NAT / session / egress policy
- 路由及回程路径
- 是否存在基于 MAC、终端指纹或交换机端口的差异化策略有了这组信息，网络人员不需要从"电脑能不能上网"重新开始，而可以直接在明确的五元组和时间窗口里查日志。
十一、这类 Case 最值得复用的排查顺序
先做网络 A/B。
同一电脑换热点；同一网络换正常电脑。先判断故障是否跟着"电脑"还是跟着"网络路径"走。
不要只看网页能不能开。
找到应用真正访问的域名、IP、端口。
把协议层说清楚。
DNS 是否成功？TCP 三次握手是否成功？TLS 是否开始？还是已经进入 HTTP/应用返回码？
抓包看数据包有没有离开网卡。
如果 SYN 已从 NIC 发出却没有返回，就不要继续在客户端配置里盲目重装。
用 A/B 一次只改变一个关键变量。
网络、网卡、源 IP、交换机端口、终端身份，按信息增益排序逐个拆。
交接网络侧时给可操作证据。
源、目的、端口、时间、成功/失败对照、抓包现象，比"这个软件打不开"有效得多。