事情的开头很朴素：我装了 TinyWall 这类"白名单式"防火墙，想把机器的出站流量管起来。用了几天嫌它太吵，就卸载了。结果卸载之后，浏览器上网一切正常，但企业微信里的文档打不开（提示被防火墙拦截），QQ 音乐也死活连不上服务器。
按常理说，软件都卸载了，拦截应该跟着走才对。这篇就记录一下这个"卸载了还在拦人"的问题是怎么查出来、又是怎么干掉的。
一、现象：网页能开，个别应用连不上
先明确故障现场，因为"能不能上网"这个说法太粗了：
- 浏览器打开网页完全正常，HTTPS 请求返回 200；
- 企业微信能登录、能收发消息，但一点开文档就报错，提示被防火墙拦截；
- QQ 音乐打开后一直连不上，播放列表刷不出来；
- 其他一些需要联网的软件也时好时坏。
这个现象本身就很有信息量：不是"上不了网"，而是"部分程序上不了网"。整机断网和按程序拦截，是两条完全不同的排查路线。
二、排查思路：分层往下挖
"部分应用断网"最容易走弯路的地方，就是一上来就去重装软件或者重置网络。我的思路是按网络栈从下往上逐层排除，每一步都留一个可验证的结论。
1. 先确认系统网络层是不是干净的
第一步不看应用，只看系统本身的连通性：
# DNS 解析是否正常
nslookup doc.weixin.qq.com
# 连通性与 TLS 是否正常
Test-NetConnection doc.weixin.qq.com -Port 443
Invoke-WebRequest https://doc.weixin.qq.com -UseBasicParsing | Select-Object StatusCode结果：DNS 解析、ICMP、TCP 443、HTTPS 实测全部正常，网页请求返回 200。
结论：底层网络是好的。 这一层排除掉之后，问题的范围立刻缩小到"谁在按程序做拦截"。
2. 再看 Windows 自带防火墙有没有背锅
# 查看三个配置文件的默认策略
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultOutboundAction, DefaultInboundAction
# 看有没有针对目标程序的阻止规则
Get-NetFirewallRule -Direction Outbound -Action Block |
Where-Object DisplayName -match "weixin|wxwork|QQMusic"结果：三个配置文件（域 / 专用 / 公用）都是默认的出站放行，也搜不到任何针对企业微信、QQ 音乐的阻止规则；启用的阻止规则只有 5 条，都是系统自带的常规项。
结论：Windows 自带防火墙也是干净的。 那拦截只能来自别的地方。
3. 把怀疑对象转向"第三方防火墙的内核残留"
这里有个容易忽略的事实：市面上这类灰白名单防火墙（TinyWall、simplewall 等）大多不是靠"改 Windows 防火墙规则"工作的，而是直接调用 WFP（Windows Filtering Platform） 在内核里注册自己的过滤提供程序（provider）、过滤子层（sublayer）和一堆过滤器（filter）。
看过往经验，这类程序卸载不干净的例子不少——卸载程序只删了 EXE 和快捷方式，留在系统里的内核过滤策略一条没动。而 WFP 的持久化策略是随系统启动自动加载的，所以"卸载之后照拦不误"完全说得通。
三、根因定位：内核里躺着的 simplewall 过滤策略
导出当前的 WFP 状态一看，问题就现形了：
# 导出当前过滤策略快照（排查用，先存一份）
netsh wfp show state file=temp\wfp_state.xml
netsh wfp show filters file=temp\wfp_filters.xml
# 看看有哪些第三方提供程序和子层还挂着
netsh wfp show providers
netsh wfp show sublayers结果非常直接：系统里还残留着一款第三方防火墙（simplewall）的内核级过滤策略，而且是激活状态。
| 残留项 | 标识 | 状态 |
|---|---|---|
| 过滤提供程序 | {b0d553e2-c6a0-4a9a-aeb8-c752483ed62f}（simplewall） | 仍在内核中注册 |
| 过滤子层 | {9fee6f59-b951-4f9a-b52f-133dcf7a4279}（simplewall） | 仍处于启用状态 |
| 常驻（persistent）过滤规则 | 引用上述提供程序 | 2873 条，随系统启动自动加载 |
对照一下系统自带的部分：
| 对象 | GUID | 判定 |
|---|---|---|
| Windows 防火墙 | {1bebc969-…}（MPSSVC） | 系统组件，保留 |
| 策略代理 | {aa6a7d87-…}（Policyagent） | 系统组件，保留 |
| 系统自带过滤规则 | — | 48 条，保留 |
| simplewall 提供程序 / 子层 / 规则 | {b0d553e2-…} / {9fee6f59-…} | 第三方残留，待清理 |
为什么偏偏是这两个应用中招
这套残留策略的工作模式是「默认阻止所有出站连接 + 应用白名单」。它的默认阻断规则（BlockConnection）挂在出站连接层上，也就是说：不在白名单里的程序，联网请求会在内核层直接被丢掉，应用侧既收不到明确的拒绝，也看不到系统防火墙的任何提示。
而当时白名单里放行的只有 chrome.exe、qqbrowser.exe、weixin.exe、powershell.exe 这几个。企业微信的文档功能并不是主进程一个人在干活，它依赖的渲染进程（wxworkweb 等）不在白名单里；QQ 音乐同理，QQMusicExternal、QQMusicService 这些组件也不在。它们的请求被内核直接丢弃，表现就是"主程序看着没事，文档打不开 / 音乐连不上"。
这正好解释了开头那个奇怪的现象：系统能上网，浏览器能上网，偏偏这两个应用不行。
为什么卸载了还在、还删不掉
顺着这条线又查了持久化存储的位置：
HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent那 2873 条规则就存在 BFE（Base Filtering Engine）服务的持久化策略区里，并且被标记为启动时加载。所以 simplewall 的卸载程序没清这些条目，它们照样会随系统启动重建。
删起来也麻烦：netsh 并没有提供删除 WFP 过滤器的子命令，想直接调 WFP API 又在本机被拒绝访问（返回 0x32）。最后是绕开 API，直接从持久化存储里按 GUID 定向清掉的。
顺带还发现两处"软件卸载后没带走"的东西，一并记下来：
- 一条残留代理配置：
127.0.0.1:7890（当时处于关闭状态，但值还在）； - 网卡协议绑定上挂着
Npcap、Capsa、Rawether等第三方抓包驱动（另有 VMware Bridge 虚拟网络组件，属正常）。
四、处置：先备份，再按步清
涉及系统内核过滤策略，属于比较危险的操作，所以第一步不是删，而是备份。
第 0 步：备份（可回滚的前提）
# 备份完整策略快照
netsh wfp show state file=temp\wfp_state.xml
netsh wfp show filters file=temp\wfp_filters.xml另外把提供程序、子层以及全部 2873 条规则的原始字节单独导了一份 JSON 存档（约 3.5 MB）——万一清完出问题，至少还有原始数据可以回滚参考。
第 1 步：删除 simplewall 残留策略（关键步骤）
要删的就三样东西：
- 持久化存储中的 simplewall 过滤提供程序：
{b0d553e2-c6a0-4a9a-aeb8-c752483ed62f} - 持久化存储中的 simplewall 过滤子层：
{9fee6f59-b951-4f9a-b52f-133dcf7a4279} - 引用该提供程序的 2873 条常驻过滤规则
思路是定位到 BFE 持久化策略区后，按 GUID 精确定位、逐类删除，而不是大范围清空。这样碰到的只有第三方那部分，Windows 自带的 MPSSVC、Policyagent 以及 48 条系统规则原样保留。
这一层有个理解上的坑：删掉持久化策略 ≠ 内核里立刻不拦了。策略是"下次加载时不再有"，而内存里加载着的过滤器还在干活。所以删完之后必须重启，才能让内核过滤引擎彻底卸载它们。
第 2 步：清理残留目录与代理
# 残留目录（移入回收站，可还原）
C:\Program Files (x86)\TinyWall
C:\ProgramData\TinyWall
%APPDATA%\TinyWall
# 残留代理配置
# ProxyServer = 127.0.0.1:7890
# ProxyOverride = <local> 等残留值代理这块清完之后，系统代理和 WinHTTP 代理都回到了直连状态。
五、验证：连通性回测与生效条件
清理动作做完后，回测了受影响业务的连通性：
Test-NetConnection doc.weixin.qq.com -Port 443
Test-NetConnection work.weixin.qq.com -Port 443
Test-NetConnection y.qq.com -Port 443
Test-NetConnection u.y.qq.com -Port 443四个域名 443 端口均已连通。同时复核了一遍还有没有别的拦截源：
- 无任何第三方防火墙的服务、驱动或进程驻留，TinyWall / simplewall 的进程与服务都不存在；
- 系统防火墙三个配置文件均为默认状态，未见针对企业微信或 QQ 音乐的封堵；
- hosts 文件干净，只有 localhost 默认项；
- 抓包类驱动（Npcap / Capsa / Rawether）不做拦截判定，保留。
验证结论
| 项目 | 结果 |
|---|---|
| simplewall 常驻规则 | 已删除 2873 条（失败 0），剩余 48 条均为系统自带 |
| 提供程序 / 子层 | 已从持久化存储删除，引用数归零 |
| 残留目录 | 3 个目录已移入回收站（可还原） |
| 残留代理 | 已清除，系统代理与 WinHTTP 代理均为直连 |
| 连通性 | 企业微信文档、QQ 音乐相关域名 443 端口全部连通 |
最后一个前提：重启。 持久化策略删掉了，但内核内存里当时仍加载着 simplewall 的活动过滤器，这部分只能靠重启内核过滤引擎或重启系统来卸载。所以完整的闭环是：清理 → 重启系统 → 再打开企业微信文档和 QQ 音乐验证。重启这一步不做，本次开机内旧过滤器可能还在工作。
六、几条经验
1. 白名单型防火墙，"卸载"不等于真的卸载。 这类工具的核心是 WFP 过滤提供程序 + 持久化规则，卸载程序常常只清表面文件，策略留在 BFE 的持久化存储里，随开机自动加载。以后卸载这类软件，值得顺手 netsh wfp show providers 看一眼。
2. 排查顺序要分层，别一上来就重置网络。"能不能上网"必须拆成"整机断网"和"按程序断网"。这次底层 DNS、ICMP、443、HTTPS 一路验证下来全部正常，一步就把范围从"网络坏了"缩小到"有人在按程序拦"。
3. 系统自带防火墙干净，不代表没有防火墙在工作。Windows 防火墙的规则和第三方 WFP 过滤器是两套东西，只看前者会漏掉后者。
4. 动手前先备份，尤其涉及内核策略。 导出策略快照 + 规则原始字节，成本很低，但决定了出事之后有没有退路。
5. 删了持久化策略记得重启。 持久化存储是"下次加载"的状态，内核里已经加载的过滤器不会因为删了存储条目就自动消失，重启才是彻底的卸载。
6. 顺手记一下副作用。 清理过程中还发现残留代理（127.0.0.1:7890）和几个抓包驱动。这类"上一款软件留下的尾巴"平时不显形，出问题时却很容易干扰判断，值得一起清掉或者至少标记出来。
整个过程其实没什么高深技巧，难的是别急着动手：先把"哪些程序不行、哪些程序行"这个现象说清楚，再按网络栈一层层验证，最后才把怀疑落到 WFP 持久化策略上。真找到那 2873 条规则的时候，前面所有"证明了这里没问题"的排除步骤，反而成了最有价值的部分。