VC++调用Windows防火墙规则：四种方案与COM实战

1. 先把场景说清楚：VC 里为什么非要碰防火墙

做 Windows 桌面端的同行大概都有过这种经历：程序装完了，图标也出来了，双击能跑，界面一切正常，唯独网络功能像被谁掐住了脖子——监听端口连不上，往外发请求一直被拒，日志里连个像样的错误码都不给你。折腾半天最后发现，是 Windows 防火墙把流量给拦了。这类问题我在实际项目里遇到过不止一次，其中一次是安装包少了放行规则，另一次是程序挂在服务里跑，用户压根看不到那个“允许访问”的弹窗。

所以只要有 VC 开发的客户端需要监听端口、发起连接、注册服务、做局域网发现，Windows 防火墙调用方式就是绕不过去的一道坎。这里说的“调用方式”，具体指的是在 Visual C++ 代码里，用哪套接口把防火墙规则写进系统、怎么查、怎么删、权限怎么拿、规则怎么保证生效。可选的路子其实有四条：最省事的netsh advfirewall命令行、代码量适中的 NetFw COM 接口（INetFwPolicy2/INetFwRules/INetFwRule）、能力最强但门槛也最高的 WFP 过滤平台，以及一些老项目里还在用的注册表直改。

这篇文章面向的是有 C++ 基础、需要在产品代码里落地防火墙规则的开发者，也照顾刚接触这块、只知道“加个例外”的新人。我会把四条路线的取舍逻辑摆开讲，重点拆 COM 接口那一套的完整实现——包括工程怎么配、属性怎么填、内存怎么管、出错怎么查，再附上实测踩过的坑和一份可以直接抄的封装思路。看完至少能做到：知道该选哪条路，写出来的代码能编译、能跑、能重复执行不出乱子。

2. 四条调用路线摆在一起比一比

选型这件事，很多人上来就问“哪个最好”，这问题本身就没法答。四条路线的定位完全不同，得先看你要求什么。你是安装包里加一条固定端口的入站规则，还是要按用户登录身份做细粒度过滤？你是要允许某个程序的所有流量，还是要按进程、按端口、按远端地址、按协议组合出复杂条件？你是跑在交互式桌面进程里，还是跑在 Session 0 的系统服务里？这些差异直接决定选型。

2.1 netsh advfirewall：命令行一把梭

netsh advfirewall firewall是最容易上手的一条路。它本质上是调用系统的命令行工具，你在 VC 里用CreateProcessW起一个进程，把参数拼好，读退出码就完事。优点是零依赖、不用碰 COM 初始化、不用管 BSTR 内存，团队里哪怕是不熟 C++ 的同事也能看懂。安装包脚本、批处理、部署工具里到处都是它的身影。

代价也很直接：每次调用都要起一个进程，冷启动开销在几十到上百毫秒量级，批量加几十条规则的时候那个耗时是能感觉出来的。更要命的是错误信息不好拿——命令失败时它把提示打到标准输出，中文系统上是 ANSI 代码页，你从管道里读出来还得转码，稍不留神就是乱码。参数拼串还有转义风险，规则名里带个引号或者路径里有空格，没处理好就直接把命令拆坏了。

我的判断是：一次性、少量、规则固定的场景用 netsh 完全够用，比如安装程序里加两三条端口规则。凡是需要根据运行时状态动态增删、需要精确错误处理、需要批量操作的，趁早换 COM。

2.2 NetFw COM 接口：官方门面，代码量适中

这是实际项目里最常用的方案。系统暴露了一组 COM 组件，CLSID_NetFwPolicy2是策略对象，从它身上能拿到INetFwRules规则集合，集合里每一条规则是一个INetFwRule。你要做的事就是创建对象、设置属性、调Add塞进去。整个过程在进程内完成，没有额外进程开销，错误以HRESULT返回，能精确到具体哪一步失败。

它的能力覆盖了绝大多数产品需求：按方向（入站/出站）、按动作（允许/阻止）、按协议（TCP/UDP/ICMP/任意）、按本地端口（支持范围和逗号列表）、按远端地址（支持*、LocalSubnet、CIDR 网段）、按程序路径、按服务名、按配置文件（域/专用/公用）、按接口类型。Windows 8 之后还有INetFwRule3，能挂LocalAppPackageId之类的属性，用来处理应用容器场景。

限制也得说清楚：它管的是“规则”，不是“数据包”。想要做深度包检测、按连接状态做策略、做应用层识别，这套接口满足不了，得上 WFP。另外它对组策略下发的规则基本无解，你能看到但删不掉。

2.3 WFP 过滤平台：能力最强，门槛也最高

WFP（Windows Filtering Platform）是内核层的过滤框架，FwpmEngineOpen0开引擎、FwpmSubLayerAdd0加子层、FwpmFilterAdd0加过滤器，链接fwpuclnt.lib，需要管理员权限。它能在多个层次上拦截和检查流量，支持基于安全标识符、基于应用 ID、基于连接元数据的复杂条件，也能拿到每个连接的详细信息。

门槛在于概念多、API 面广，一套过滤器写下来代码量是 COM 方案的几倍，调试起来也更麻烦——过滤器不生效的时候，你得一层层排查是不是子层权重不对、是不是被更高优先级的过滤器先匹配走了。还有一个很实际的细节：用FWPM_SESSION_FLAG_DYNAMIC打开的会话，句柄一关过滤器就自动清理，这对常驻进程挺友好，但也意味着你不能指望它在进程退出后还留着。

我的经验是，普通业务软件的“放行某个端口/某个程序”这类需求，上 WFP 属于用力过猛。真需要它的场合通常是安全软件、流量整形、按用户身份做网络隔离这类。

2.4 注册表直改：能跑，但别在生产上用

老代码里偶尔能看到直接往HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules下面写字符串值的做法，格式类似v2.10|Action=Allow|Active=TRUE|Dir=In|Protocol=6|LPort=9000|Name=xxx|。这招确实能生效，但坑一堆：格式版本会变、字段语义没有文档保证、写完往往要重启相关服务才刷新、并发写有冲突风险、出错还查不出来。

这条路我的态度很明确：只在逆向分析或者救急排查的时候看看，产品代码里一条都不要写。省下的那点 COM 代码量，后面维护的时候要加倍还回去。

下面这张表把四者的关键差异拉平了看，选型的时候对着自己的需求勾一遍就行。

3. COM 路线的核心细节拆解

选定 COM 之后，真正让人栽跟头的地方往往不是 API 调用本身，而是周边那些“没人明说”的细节：头文件怎么包含、初始化用哪种套间、属性类型为什么是VARIANT、字符串为什么必须手工释放。这一节把这些掰开。

3.1 工程配置与初始化：从能编译到能创建对象

头文件就一个<netfw.h>，在 Windows SDK 的 um 目录下。需要确保工程的_WIN32_WINNT定义足够高（至少 0x0600），否则部分接口声明会被条件编译掉，表现为“明明有这个类却找不到”。链接方面要加ole32.lib和oleaut32.lib，前者提供 COM 基础设施，后者提供SysAllocString系列。

CLSID 和 IID 的获取有两种写法。一种是链接uuid.lib后直接用CLSID_NetFwPolicy2、IID_INetFwPolicy2这些符号；另一种是用__uuidof，让编译器从类型库里取。后者更省事，也不容易出现链接顺序问题：

INetFwPolicy2* pPolicy = nullptr; HRESULT hr = CoCreateInstance( __uuidof(NetFwPolicy2), nullptr, CLSCTX_INPROC_SERVER, __uuidof(INetFwPolicy2), reinterpret_cast<void**>(&pPolicy));

初始化套间这块，我一般用CoInitializeEx(nullptr, COINIT_APARTMENTTHREADED)。防火墙这套组件是进程内组件，STA 和 MTA 都能用，但如果你在一个已经有 UI 线程的进程里调用，STA 更稳妥；反过来在纯后台线程里，MTA 能省掉消息泵的麻烦。关键是初始化和反初始化必须配对，而且要在同一个线程里成对出现。我见过把CoInitializeEx放在主线程、CoUninitialize放在工作线程的代码，跑久了就出各种诡异的RPC_E_*错误。

还有一个容易被忽略的点：CoCreateInstance成功不代表后面就一路畅通。如果 Windows 防火墙服务（mpssvc）出于某种原因没在跑，后续拿规则集合的操作会直接失败。所以拿到pPolicy之后，我习惯先get_Rules试一下，失败就当作整体不可用处理，别等到真正写规则的时候才暴露。

3.2 INetFwRule 的属性模型与常见取值

INetFwRule上的属性看着多，实际用起来就那么十来个。麻烦在于它们的类型不统一：有的是long，有的是BSTR，有的是VARIANT_BOOL。类型传错编译器不一定报错（因为有隐式转换），运行时就给你一个莫名其妙的E_INVALIDARG。

方向、动作、协议这三个是long：

配置文件用的是位掩码，可以按位或组合：

Enabled和EdgeTraversal是VARIANT_BOOL，也就是VARIANT_TRUE（-1）和VARIANT_FALSE（0），不能直接塞true/false。这一点特别容易翻车：C++ 的true转成long是 1，赋给VARIANT_BOOL属性后行为不确定，有的系统版本上会被当成“非真非假”处理。

Name、Grouping、LocalPorts、RemoteAddresses、ApplicationName、ServiceName、Description这些是BSTR。端口字符串的格式有讲究：单端口写"9000"，范围写"9000-9100"，多个值用逗号分隔"80,443,8080-8090"。远端地址支持"*"（任意）、"LocalSubnet"（本地子网）、"192.168.1.0/24"（CIDR），多个用逗号隔开。

Grouping这个属性值得单独说一句——它决定了规则在防火墙管理界面里归到哪个分组下。产品代码里如果不设，所有规则都散落在列表里，用户看着一头雾水，卸载的时候也不好批量清理。我一般统一设成产品名加模块名的形式，方便后续按组枚举删除。

3.3 字符串与变体的内存管理：泄漏就藏在这几行

COM 这套接口最阴的地方就是内存。BSTR不是std::wstring，它有独立的前缀长度头和分配器，必须用SysAllocString分配、SysFreeString释放。你传给put_Name的BSTR在属性设置完成后就可以释放了（组件内部会拷贝），但从get_Name拿回来的BSTR必须由你释放，否则每查一次泄漏一块。

我的习惯是写一个极简的 RAII 包装，把SysAllocString/SysFreeString包起来，函数里就不用到处写释放语句了：

struct BstrHolder { BSTR p = nullptr; explicit BstrHolder(const std::wstring& s) : p(SysAllocString(s.c_str())) {} ~BstrHolder() { if (p) SysFreeString(p); } BstrHolder(const BstrHolder&) = delete; BstrHolder& operator=(const BstrHolder&) = delete; operator BSTR() const { return p; } };

VARIANT那边要记得VariantInit和VariantClear。枚举规则集合的时候，IEnumVARIANT::Next填进来的VARIANT里装的是VT_DISPATCH，你需要QueryInterface到INetFwRule，用完Release，然后VariantClear。少一步就是泄漏。

提示：调试期可以用任务管理器的句柄数、私有字节数做个粗筛。如果发现调用几千次之后内存稳步上涨，十有八九是BSTR或者接口指针没释放干净。

4. 动手写：从添加规则到删除规则的完整实现

理论说再多不如一段能跑的代码。下面这套代码我在实际项目里用过，做了精简，去掉业务相关的部分，保留通用骨架。工程是 Unicode 字符集、x64 平台，需要管理员权限运行。

4.1 一条入站端口规则的完整代码

先看最核心的添加逻辑。这个函数做了三件事：拿规则集合、创建规则对象、逐项设属性后提交。

#include <windows.h> #include <netfw.h> #include <comdef.h> #include <string> #pragma comment(lib, "ole32.lib") #pragma comment(lib, "oleaut32.lib") static HRESULT AddTcpInboundRule( INetFwPolicy2* pPolicy, const std::wstring& name, const std::wstring& group, const std::wstring& localPorts, const std::wstring& remoteAddrs, long profiles) { if (!pPolicy) return E_POINTER; INetFwRules* pRules = nullptr; HRESULT hr = pPolicy->get_Rules(&pRules); if (FAILED(hr)) return hr; INetFwRule* pRule = nullptr; hr = CoCreateInstance(__uuidof(NetFwRule), nullptr, CLSCTX_INPROC_SERVER, __uuidof(INetFwRule), reinterpret_cast<void**>(&pRule)); if (FAILED(hr)) { pRules->Release(); return hr; } BSTR bName = SysAllocString(name.c_str()); BSTR bGroup = SysAllocString(group.c_str()); BSTR bPorts = SysAllocString(localPorts.c_str()); BSTR bRemote = SysAllocString(remoteAddrs.c_str()); hr = pRule->put_Name(bName); if (SUCCEEDED(hr)) hr = pRule->put_Grouping(bGroup); if (SUCCEEDED(hr)) hr = pRule->put_Direction(NET_FW_RULE_DIR_IN); if (SUCCEEDED(hr)) hr = pRule->put_Action(NET_FW_ACTION_ALLOW); if (SUCCEEDED(hr)) hr = pRule->put_Protocol(NET_FW_IP_PROTOCOL_TCP); if (SUCCEEDED(hr)) hr = pRule->put_LocalPorts(bPorts); if (SUCCEEDED(hr)) hr = pRule->put_RemoteAddresses(bRemote); if (SUCCEEDED(hr)) hr = pRule->put_Profiles(profiles); if (SUCCEEDED(hr)) hr = pRule->put_Enabled(VARIANT_TRUE); if (SUCCEEDED(hr)) hr = pRules->Add(pRule); SysFreeString(bName); SysFreeString(bGroup); SysFreeString(bPorts); SysFreeString(bRemote); pRule->Release(); pRules->Release(); return hr; }

调用侧大概长这样：

int wmain() { HRESULT hrCo = CoInitializeEx(nullptr, COINIT_APARTMENTTHREADED); if (FAILED(hrCo)) return 1; INetFwPolicy2* pPolicy = nullptr; HRESULT hr = CoCreateInstance(__uuidof(NetFwPolicy2), nullptr, CLSCTX_INPROC_SERVER, __uuidof(INetFwPolicy2), reinterpret_cast<void**>(&pPolicy)); if (SUCCEEDED(hr)) { hr = AddTcpInboundRule(pPolicy, L"MyApp TCP 9000", L"MyApp", L"9000", L"*", NET_FW_PROFILE2_ALL); if (FAILED(hr)) { wprintf(L"添加失败, HRESULT=0x%08X\n", hr); } pPolicy->Release(); } CoUninitialize(); return SUCCEEDED(hr) ? 0 : 2; }

这段代码有一个设计取舍值得说：属性设置我用了链式的if (SUCCEEDED(hr))，而不是每步都单独判断。原因是这几个put_调用彼此有依赖（比如没设Protocol就设LocalPorts，有些系统版本上会拒绝），一旦某步失败，后面继续设也没意义。链式写法既保证短路，又让代码不至于铺开成二十行。

4.2 按程序路径放行与出站规则

按程序放行是最常见的需求之一，尤其是客户端要从本地往外连。注意这时候LocalPorts和RemoteAddresses可以不设，但ApplicationName必须是完整路径。如果程序装在不同盘符下，路径就得运行时获取，不能硬编码。

static HRESULT AddAppOutboundRule( INetFwPolicy2* pPolicy, const std::wstring& name, const std::wstring& group, const std::wstring& exePath, long profiles) { if (!pPolicy) return E_POINTER; INetFwRules* pRules = nullptr; HRESULT hr = pPolicy->get_Rules(&pRules); if (FAILED(hr)) return hr; INetFwRule* pRule = nullptr; hr = CoCreateInstance(__uuidof(NetFwRule), nullptr, CLSCTX_INPROC_SERVER, __uuidof(INetFwRule), reinterpret_cast<void**>(&pRule)); if (FAILED(hr)) { pRules->Release(); return hr; } BSTR bName = SysAllocString(name.c_str()); BSTR bGroup = SysAllocString(group.c_str()); BSTR bApp = SysAllocString(exePath.c_str()); hr = pRule->put_Name(bName); if (SUCCEEDED(hr)) hr = pRule->put_Grouping(bGroup); if (SUCCEEDED(hr)) hr = pRule->put_Direction(NET_FW_RULE_DIR_OUT); if (SUCCEEDED(hr)) hr = pRule->put_Action(NET_FW_ACTION_ALLOW); if (SUCCEEDED(hr)) hr = pRule->put_Protocol(NET_FW_IP_PROTOCOL_ANY); if (SUCCEEDED(hr)) hr = pRule->put_ApplicationName(bApp); if (SUCCEEDED(hr)) hr = pRule->put_Profiles(profiles); if (SUCCEEDED(hr)) hr = pRule->put_Enabled(VARIANT_TRUE); if (SUCCEEDED(hr)) hr = pRules->Add(pRule); SysFreeString(bName); SysFreeString(bGroup); SysFreeString(bApp); pRule->Release(); pRules->Release(); return hr; }

路径这里有个坑：传进去的路径如果带长文件名或者 UNC 路径，某些系统版本上匹配会失败。稳妥的写法是先用GetLongPathNameW转一遍，再传进去。另外ApplicationName匹配的是文件路径字符串，程序升级换了安装目录，旧规则就废了——这也是为什么安装时要先删旧规则再建新的。

4.3 规则查询、幂等删除与批量清理

删除规则的思路是：按名字从集合里Item取出来，拿到它的Name，再调Remove。这里为什么要绕一圈？因为Remove要的参数是规则名，而Item返回的是规则对象，得先把名字取回来。

static HRESULT RemoveRuleByName(INetFwPolicy2* pPolicy, const std::wstring& name) { if (!pPolicy) return E_POINTER; INetFwRules* pRules = nullptr; HRESULT hr = pPolicy->get_Rules(&pRules); if (FAILED(hr)) return hr; BSTR bName = SysAllocString(name.c_str()); INetFwRule* pRule = nullptr; hr = pRules->Item(bName, &pRule); SysFreeString(bName); if (SUCCEEDED(hr) && pRule) { BSTR bReal = nullptr; if (SUCCEEDED(pRule->get_Name(&bReal)) && bReal) { hr = pRules->Remove(bReal); SysFreeString(bReal); } pRule->Release(); } pRules->Release(); return hr; }

批量清理按分组来更靠谱。枚举整个集合，把Grouping匹配的记录挑出来，收集名字，再逐个删。不要边枚举边删，集合在遍历过程中被修改，结果不可预期，我吃过这个亏——删了一半就再也枚举不出来了。正确做法是先收集到一个std::vector<std::wstring>里，遍历完了再统一删。

static HRESULT RemoveRulesByGroup(INetFwPolicy2* pPolicy, const std::wstring& group) { if (!pPolicy) return E_POINTER; INetFwRules* pRules = nullptr; HRESULT hr = pPolicy->get_Rules(&pRules); if (FAILED(hr)) return hr; std::vector<std::wstring> toDelete; IUnknown* pUnkEnum = nullptr; hr = pRules->get__NewEnum(&pUnkEnum); if (SUCCEEDED(hr) && pUnkEnum) { IEnumVARIANT* pEnum = nullptr; if (SUCCEEDED(pUnkEnum->QueryInterface(IID_IEnumVARIANT, reinterpret_cast<void**>(&pEnum)))) { VARIANT var; VariantInit(&var); ULONG fetched = 0; while (pEnum->Next(1, &var, &fetched) == S_OK && fetched == 1) { if (var.vt == VT_DISPATCH && var.pdispVal) { INetFwRule* pRule = nullptr; if (SUCCEEDED(var.pdispVal->QueryInterface(IID_INetFwRule, reinterpret_cast<void**>(&pRule)))) { BSTR bGroup = nullptr, bName = nullptr; if (SUCCEEDED(pRule->get_Grouping(&bGroup)) && bGroup) { if (group == bGroup && SUCCEEDED(pRule->get_Name(&bName)) && bName) { toDelete.push_back(bName); } SysFreeString(bGroup); } if (bName) SysFreeString(bName); pRule->Release(); } } VariantClear(&var); VariantInit(&var); } pEnum->Release(); } pUnkEnum->Release(); } for (const auto& n : toDelete) { BstrHolder b(n); hr = pRules->Remove(b); } pRules->Release(); return S_OK; }

幂等性是产品代码的硬要求。安装程序可能被用户点两次，修复功能可能重复执行，所以“先删后加”是标准动作。但要注意，直接对不存在的规则调Remove会返回失败（HRESULT是0x80070002一类），这不是错误，写代码的时候要区分对待，别把“本来就不存在”当成异常往上抛。

4.4 netsh 与 PowerShell 的等价写法对照

有些场合确实用命令行更合适，比如安装脚本、现场排障。把等价命令记熟能省很多事。下面拿“放行 TCP 9000 入站、全部配置文件”做对照：

netsh advfirewall firewall add rule name="MyApp TCP 9000" dir=in action=allow protocol=TCP localport=9000 profile=any group="MyApp" enable=yes

New-NetFirewallRule -DisplayName "MyApp TCP 9000" -Direction Inbound ` -Protocol TCP -LocalPort 9000 -Action Allow -Profile Any -Group "MyApp" -Enabled True

删除和查询：

netsh advfirewall firewall delete rule name="MyApp TCP 9000" dir=in protocol=TCP localport=9000 netsh advfirewall firewall show rule name="MyApp TCP 9000" verbose

Remove-NetFirewallRule -DisplayName "MyApp TCP 9000" Get-NetFirewallRule -DisplayName "MyApp TCP 9000" | Format-List *

在 VC 里起进程的话，CreateProcessW记得设STARTF_USESHOWWINDOW加SW_HIDE，否则用户会看到一个黑框一闪而过。命令行字符串要放在可写的缓冲区里，别直接传字符串字面量：

std::wstring cmd = L"netsshh ..."; // 实际使用时拼完整命令 std::vector<wchar_t> buf(cmd.begin(), cmd.end()); buf.push_back(L'\0'); STARTUPINFOW si = { sizeof(si) }; si.dwFlags = STARTF_USESHOWWINDOW; si.wShowWindow = SW_HIDE; PROCESS_INFORMATION pi = {}; BOOL ok = CreateProcessW(nullptr, buf.data(), nullptr, nullptr, FALSE, CREATE_NO_WINDOW, nullptr, nullptr, &si, &pi); if (ok) { WaitForSingleObject(pi.hProcess, 15000); DWORD code = 0; GetExitCodeProcess(pi.hProcess, &code); CloseHandle(pi.hThread); CloseHandle(pi.hProcess); }

CREATE_NO_WINDOW和SW_HIDE双保险，控制台窗口才不会闪。等待要设超时，15 秒是个经验值，netsh在系统繁忙的时候确实会卡住。

5. 踩坑实录：权限、生效、编码、资源

这一节是我这些年攒下来的问题清单，基本覆盖了实际会遇到的大半情况。有些坑第一次踩的时候查了很久，写下来省得后面的人重复踩。

5.1 拒绝访问的几种成因

0x80070005（E_ACCESSDENIED）是出现频率最高的失败码，但成因不止一种。

第一种最直接：进程没有管理员权限。写防火墙规则必须提权，这是硬性要求。解决方式是给 exe 加清单文件，设requestedExecutionLevel level="requireAdministrator"；或者程序启动时检测当前令牌，判断是否在管理员组里，不是就ShellExecuteEx带runas重新拉起自己。别用IsUserAnAdmin判断，它只检查用户是否属于管理员组，UAC 开启时普通启动的进程仍然没提权，两者不是一回事。正确的判断方式是OpenProcessToken加GetTokenInformation查TokenElevation。

第二种：进程本身提权了，但运行在受限的作业对象或者应用容器里，访问 COM 组件被拦。这种在沙箱化的宿主进程里会遇到，排查方法是看进程是否被放进了低完整性级别，Process Explorer里看 Integrity 那一栏就能确认。

第三种：防火墙服务本身状态异常。mpssvc被禁用或者启动失败的时候，CoCreateInstance可能成功（组件加载了），但get_Rules直接返回拒绝访问。这时候要去服务管理器里看服务状态，别一头扎进代码里找。

第四种比较隐蔽：32 位进程在 64 位系统上跑，路径里含重定向目录。虽然防火墙的 COM 接口本身不受文件系统重定向影响，但如果你的代码顺带读注册表配置，可能会读到Wow6432Node下面那一份，导致行为不一致。

5.2 规则加上了却不生效

这种问题最折磨人，因为代码返回成功，规则也在列表里能看到，就是不生效。按下面这个顺序排查基本能定位到。

先看配置文件对不对。你设了NET_FW_PROFILE2_DOMAIN，结果用户机器是家用网络，当前激活的是“专用”配置文件，那规则根本没启用。稳妥做法是设NET_FW_PROFILE2_ALL，除非业务上确实需要区分网络类型。

再看规则是不是被更严格的规则压住了。防火墙的匹配逻辑是“阻止优先于允许”，同一流量如果同时命中一条阻止规则和一条允许规则，结果是阻止。这时候你要去规则列表里找找有没有别的软件或者系统内置策略挡着。

然后看EdgeTraversal。这条属性跟设备穿越有关，某些场景下不设会导致规则行为不符合预期，一般设VARIANT_FALSE明确一下。

还有一个很多人不知道的点：已经在建立的连接不会因为新加的规则而改变状态。规则对新建连接生效，如果测试的时候用的是一条早就存在的长连接，那规则加完了也看不出变化。测试方法很简单，把连接断掉重连一次。

ApplicationName匹配失败也是常见原因。路径大小写、短文件名、结尾反斜杠，都可能影响匹配。我在一次现场问题里就见过，安装程序写进去的是短路径PROGRA~1，实际程序跑起来是长路径，两条规则对不上。

5.3 静默安装与系统服务里的特殊处理

安装程序是典型的静默执行场景，用户看不到任何界面。这里的关键是别指望那个“允许访问”的弹窗。用户点取消之后，系统会自动生成一条阻止规则，之后你的程序就再也连不上了，除非用户自己去防火墙界面里删。

所以安装包里主动加规则是必须的。加的时候注意几点：规则名要带产品标识，卸载时能精确删掉；Grouping要设，方便用户在界面上识别；端口要跟实际监听端口一致，别写死一个就完事，服务端和客户端用的端口往往不是一个。

跑在系统服务里的时候情况又不一样。服务如果是LocalSystem账户，权限足够，直接调 COM 没问题。但要注意服务的启动类型和依赖关系——如果服务在mpssvc启动之前就开始跑，第一次调用必然失败。加个重试逻辑，失败后等两秒再试，最多试五次，能覆盖绝大多数启动顺序问题。

服务里调 COM 还有套间的问题。服务主线程不跑消息泵，用 STA 的话，跨线程调 COM 会因为没有消息循环而卡死。我一般在服务工作线程里用COINIT_MULTITHREADED，配合CoInitializeSecurity设一下安全级别，整套调用就顺了。

5.4 常见问题速查表

把上面这些整理成一张表，现场排障的时候对着看。

6. 工程化封装：让调用代码经得起反复执行

前面写的都是单点功能，真放到产品里还得往上包一层。原因很简单：这类代码会被安装程序调、被主程序调、被修复工具调、被卸载程序调，调用点一多，任何一处写错都是隐患。封装的目标是把“正确用法”变成默认用法，把“错误用法”变成编译不过。

6.1 封装接口设计：只暴露业务语义

我的做法是定义一个薄接口，对外只暴露业务动作，不暴露 COM 类型。类似这样：

class IFirewallPolicy { public: virtual ~IFirewallPolicy() = default; virtual bool EnsureTcpInbound(const std::wstring& name, const std::wstring& group, const std::wstring& ports, const std::wstring& remote) = 0; virtual bool EnsureAppOutbound(const std::wstring& name, const std::wstring& group, const std::wstring& exePath) = 0; virtual bool RemoveByGroup(const std::wstring& group) = 0; virtual std::wstring LastError() const = 0; };

注意接口里所有方法都叫Ensure*而不是Add*。这不是玩文字游戏，而是把幂等语义写进名字里——调用方看到Ensure就知道重复调用是安全的，不用再自己去想“我是不是要先删一下”。实现内部就是“先按名字删，再按参数加”，删的时候忽略“不存在”的错误。

内部实现上，INetFwPolicy2对象在构造时创建一次，之后所有操作复用同一个指针。这一点在批量操作时差别很明显：一个循环里加二十条规则，复用对象的方式比每次新建快一个数量级。析构时统一Release，配上CoInitializeEx的成对调用，整个生命周期就干净了。

错误处理上，我习惯把最后一次失败的位置和HRESULT都记下来，LastError()返回一句人类可读的描述，同时把原始码打到日志里。现场排查的时候，一句“添加规则失败在 put_LocalPorts，错误码 0x80070057”能省下半小时的猜测。

6.2 命名规范与分组：给未来留条退路

规则名怎么起，看着是小事，实际影响很大。格式不统一的话，卸载时你根本不知道自己建了哪些。我的习惯是三段式：产品名_模块名_用途，中间用空格或者下划线分隔，全英文，不带中文和特殊字符。

举几个实际的例子：MyApp Core TCP 9000、MyApp Sync UDP 5353、MyApp Updater Out。名字里带上协议和端口，运维在现场用netsh advfirewall firewall show rule name=all一眼就能找到。

Grouping统一设成产品名。这样用户打开防火墙高级设置，所有相关规则聚在一起，看着清爽；卸载程序里按分组枚举删除，一条不漏；排查冲突的时候也能快速区分“这是我们自己的”还是“别的软件的”。

还有一个细节：规则名不要用随机数或者时间戳。有些人为了“每次都新建”会这么干，结果是每跑一次多一条废规则，跑一百次就有一百条，用户还没法在界面上分辨。用固定名字配幂等逻辑才是正解。

6.3 失败回滚与日志：出问题时能自证清白

产品代码里加规则，最怕的是“加了一半失败”。比如三条规则，前两条成功，第三条因为端口参数非法失败了，结果系统处于一个半开状态，功能时好时坏。所以我在封装里做了一层事务式处理：把这次要应用的规则集合先算出来，先全部删掉旧的，再逐条加新的，中途任何一条失败，就把已经加上的按分组清掉，恢复到调用前的状态。

日志这块，我建议至少记四类信息：调用入口的参数、每个HRESULT的原始值、规则最终是否落在集合里（用Item再查一次验证）、以及操作耗时。最后这个看着多余，实际上很有用——某次发现一条规则的添加耗时突然从十几毫秒涨到两秒多，追下去是用户机器上装了某个安全软件，每次规则变更它都要做一次全盘匹配。这种信息没有耗时日志根本发现不了。

还有一个建议：把防火墙操作做成配置驱动的，而不是代码里硬编码端口。业务演进中端口会变，规则跟着变，写死的话每次都要改代码重新发版。做成一个规则描述文件，加载后循环应用，运维还能现场调，灵活很多。

7. 我在实际项目里的一点体会

把这几套方案都用过一遍之后，我的选择顺序基本固定下来了：业务功能里的规则管理走 COM 封装，安装脚本里的固定规则用 netsh，只有在需要按用户身份做细粒度网络控制的时候才考虑 WFP，注册表那条路一次都没再碰过。

真正让我省心的不是接口选型，而是那层封装和那套命名规范。规则名统一、分组统一、幂等保证、失败回滚、日志可查，这五件事做到位之后，防火墙这块的功能基本就不再出现在线上问题列表里了。反倒是早期图省事、直接在业务代码里裸调INetFwRule的那批模块，隔三岔五就要去现场看一次。

如果只让我留一句经验，那就是：在动手写Add之前，先想清楚怎么把它删掉。删除逻辑写好了，添加逻辑自然就规矩了。