某桌面应用（DeepSeek Harness，Electron 架构）安装后启动即报错：“The application could not start or stopped unexpectedly. fetch failed”。折腾一下午，先后怀疑过第三方杀软、企业加密软件、Winsock 协议栈，最后用系统自带的抓包工具抓到真凶：Windows 防火墙自己把本地回环（127.0.0.1）的入站流量拦了。把完整过程记录下来，下次遇到同类问题可以按图索骥。
一、故障现象
- 应用启动弹窗：“DeepSeek Harness is unavailable — The application could not start or stopped unexpectedly. fetch failed”
- 崩溃日志（
C:\Users\<用户名>\AppData\Roaming\@deepseek-ai\dsh-desktop\logs\crash-*.log）里的关键一行：
Error: connect ETIMEDOUT 127.0.0.1:8293这类 Electron 应用的前端界面必须连接本机 8293 端口的后台服务。注意错误是 ETIMEDOUT（超时）而不是 ECONNREFUSED（拒绝连接）——“没人监听”会秒拒，“超时”说明包被静默丢弃了，这是排查的第一个重要线索。
二、快速自测：回环是不是坏了
用 Python 一行脚本自证：自己监听一个端口，然后自己连自己。
python -c "
import socket, threading, time
srv = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
srv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
srv.bind(('127.0.0.1', 8293)); srv.listen(1)
threading.Thread(target=lambda: srv.accept(), daemon=True).start()
time.sleep(0.3)
c = socket.socket(socket.AF_INET, socket.SOCK_STREAM); c.settimeout(5)
try:
c.connect(('127.0.0.1', 8293)); print('回环正常')
except Exception as e:
print('回环失败:', type(e).__name__)
"结果：监听器明明活着，连接却超时。换一个不相干的端口也一样。再补一刀：ping 127.0.0.1 直接报“一般故障”、100% 丢包。——回环在本机被系统级拦截，与应用无关。
三、三个被排除的“嫌疑人”（冤案记录）
排查路上先后冤枉了三个，逐一用证据排除，这个过程比结论更值得记下来：
- 腾讯电脑管家：实时防护服务（QQPCRTP.exe）开机自启、内核驱动 QQSysMonX64 常驻，确实具备拦截能力。但卸载并重启后，回环依旧不通——排除。
- 亿赛通 DocGuard（企业文档加密/DLP）：内核驱动 ProcessCtrl64.sys + EstVPN 进程，典型嫌疑对象。卸载后依旧不通——排除。
- Winsock / TCP-IP 协议栈损坏：执行
netsh winsock reset、netsh int ip reset并重启——依旧不通。排除。
教训：没有证据的怀疑只是在制造工作量。真正的突破口是下一步——让系统自己招供。
四、实锤：用 WFP 抓包抓“现行”
Windows filtering Platform（WFP）自带丢包审计。以管理员身份：
netsh wfp capture start
ping -n 2 127.0.0.1
netsh wfp capture stop生成的 wfpdiag.cab 解压后分析 wfpdiag.xml，丢包事件清清楚楚：
filterId: 129351
名称: Query User
提供程序: FWPM_PROVIDER_MPSSVC_WF ← Windows 防火墙本体
拦截层: FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4（入站连接审核层）
动作: FWP_ACTION_BLOCK拦截者就是 Windows 防火墙的默认入站拦截规则（“Query User”），TCP 连接和 ICMP echo（ping）全被它丢掉。
五、深层原因
继续查防火墙配置（netsh advfirewall show allprofiles），发现两个关键点：
防火墙策略 BlockInbound,AllowOutbound ← 默认入站全拒
LocalFirewallRules N/A (仅 GPO 存储) ← 本地新建规则不生效- 防火墙处于“仅 GPO 存储”模式：本地添加的放行规则被忽略，只有组策略下发的规则生效；而这台机器不在域里、也没有任何 GPO 规则——等于入站流量无人放行，全部落到默认拒绝上，包括 127.0.0.1 回环。
- 为什么“有监听的端口超时、没监听的端口拒绝”？SYN 到达时若存在监听器，会进入 ALE_AUTH_RECV_ACCEPT 审核层被 BLOCK（表现：超时）；无监听器时协议栈在更低层直接回 RST，根本到不了审核层（表现：拒绝连接）。现象与机制完全吻合。
六、修复（管理员权限执行）
向防火墙写入回环放行规则——来源和目的地都限定 127.0.0.1，只放开“本机自己连自己”，对外暴露面不变：
netsh advfirewall firewall add rule name="Allow Loopback In TCP v4" dir=in action=allow protocol=TCP localip=127.0.0.1 remoteip=127.0.0.1
netsh advfirewall firewall add rule name="Allow Loopback In UDP v4" dir=in action=allow protocol=UDP localip=127.0.0.1 remoteip=127.0.0.1
netsh advfirewall firewall add rule name="Allow Loopback In ICMPv4" dir=in action=allow protocol=icmpv4:8,any
netsh advfirewall firewall add rule name="Allow Loopback In ICMPv6" dir=in action=allow protocol=icmpv6:128,any立即生效，无需重启。
踩坑提示：netsh 和 PowerShell 的 New-NetFirewallRule 都拒绝为 IPv6 环回地址（::1）创建规则（报错“已指定未指定的多播、广播或环回 IPv6 地址”）——这是系统设计限制，不是语法问题。实际上 Windows 软件几乎都用 IPv4 回环，影响可忽略。
七、验证结果
| 测试项 | 修复前 | 修复后 |
|---|---|---|
| ping 127.0.0.1 | 一般故障，100% 丢包 | 0% 丢包，0ms |
| TCP 回环连接（有监听） | 超时（5 秒） | 11ms 打通 |
| UDP 回环收发 | 被丢弃 | 成功 |
| DeepSeek Harness 启动 | fetch failed 崩溃 | 正常启动，8293 建立连接 |
八、按图索骥速查表
下次遇到“某软件连不上本机端口 / localhost 服务超时”，按这个顺序来：
- 看错误码：ETIMEDOUT=被静默丢弃；ECONNREFUSED=没人监听。两个方向完全不同。
- Python 回环自测脚本自证回环好坏（见第二节）。
ping 127.0.0.1：回环通不通的最快判据。- 管理员执行
netsh wfp capture start/stop抓包，让系统指出拦截的过滤器名字——别猜，抓现行。 - 确认是防火墙后，检查
netsh advfirewall show allprofiles里的“LocalFirewallRules”是否为“仅 GPO 存储”。 - 按第六节命令补回环放行规则。
附：常用诊断命令清单
# 谁在监听某端口
netstat -ano | findstr 8293
# 防火墙配置总览
netsh advfirewall show allprofiles
# WFP 丢包抓包（管理员）
netsh wfp capture start
netsh wfp capture stop
# WFP 过滤器/状态导出（管理员）
netsh wfp show filters file=filters.xml
netsh wfp show state file=state.xml
# Winsock 目录（查 LSP 劫持）
netsh winsock show catalog
# 协议栈重置（管理员，需重启）
netsh winsock reset
netsh int ip reset完。整个案例的教训就一句话：网络问题，先抓包、再下结论。