“Windows防火墙”这四个字，大多数人第一次真正注意到它，是在某个下午——程序明明启动了、端口也监听着，外面就是连不进来。我印象最深的一次是几年前把一个内部小工具从开发机搬到另一台机器上，进程活得好好的，本机curl打得通，局域网里另一台机器死活超时。查了快两个小时，最后发现那台机器的网络位置被判成了“公用”，公用配置文件下压根没有对应的入站放行规则，而开发机上我早就在弹窗里随手点过“允许访问”。从那以后我就养成一个习惯：任何要对外服务的东西上线之前，先把防火墙规则一条条写清楚，而不是等出问题再回头翻。

这篇就把这个习惯拆开讲。从“它到底在拦什么”入手，讲清三种网络配置文件的关系；再讲第一条规则怎么加、端口和协议怎么选、作用域怎么收敛；然后是命令行和 PowerShell 的批量玩法、日志怎么开、规则不生效按什么顺序查；最后聊几个我自己踩过、也见过别人反复踩的场景。零基础可以顺着读，做过几年运维的可以直接跳到第三节往后找能抄的东西。

1. 三种网络配置文件：同一台机器上的三套独立策略

先把最容易被忽略的一层讲清楚。Windows 防火墙不是“一个开关”，而是三套互相独立、各自带开关和规则集的策略，分别在域（Domain）、专用（Private）、公用（Public）三个配置文件下生效。同一时刻，机器上只有一套策略在起作用，具体是哪套，由系统根据当前网络连接的位置判定。

1.1 域、专用、公用到底按什么判定

判定逻辑不是让你手选的，而是由网络位置感知（NLA）先做一轮判断，再允许你在设置里改。加入域的机器，能联系到域控制器时，网络自动归为“域”；除此之外，你第一次连接某个网络时，系统会弹一个小面板问你“是否允许此电脑被此网络上的其他电脑发现”，选“是”通常归为专用，选“否”归为公用。这个初判的依据是网络本身的一些特征，比如网关 MAC、是否被标记为共享网络等。

三者的典型使用场景和默认宽松度差别很大，我用一张表说明：

最容易出问题的就是最后一行。很多公司内网用的地址段，Windows 并不认识，NLA 探测失败时会保守地判成“公用”。这时候你按“专用”的思路配了规则，实际生效的是“公用”那一套，自然不通。

改判定的地方有两处，图形界面在“设置 > 网络和 Internet > 属性”里，把“网络配置文件类型”从公用切到专用；命令行更直接：

Get-NetConnectionProfile Set-NetConnectionProfile -InterfaceAlias "以太网" -NetworkCategory Private

第一条看清楚当前每个网卡被判成了什么，第二条手动纠正。我一般会在部署脚本里先跑一次Get-NetConnectionProfile，把结果记到部署日志里，后面出问题第一眼就能排除这一层。

提示：切换网络位置会立刻改变生效的策略集。一个本来能被访问的服务，可能因为你换了个 Wi-Fi 就断了，这不是服务坏了，是策略换了。

1.2 默认“入站全拦、出站全放”意味着什么

三个配置文件在出厂状态下都遵循同一套默认动作：入站阻止、出站允许，除非有规则明确匹配。这句话要拆成两层理解。

第一层，入站阻止是“默认拒绝”，意思是任何从外部主动发起的连接，只要没有一条允许规则精确匹配上，一律丢弃。注意是丢弃（drop）而不是拒绝（reject），对外表现为连接超时而不是立即报错，这也是为什么防火墙问题经常被误判成“网络不通”“服务没起来”。

第二层，出站允许是“默认放行”，这意味着本机上的任何程序都可以自由往外连，防火墙在出站方向上基本是个摆设。这个默认值在安全上是偏宽松的，但对日常使用足够省事——真要做出站限制，你得先把所有需要联网的程序、系统组件、更新服务一条条列出来，维护成本很高。我的建议是：普通办公和开发机上保持出站默认放行，只在有明确管控需求的机器上收紧。

理解这两层之后，很多疑惑就自然解开了。比如“为什么我放行了端口还是连不上”——很可能你放行的是出站方向，而入站方向还堵着；再比如“为什么本机能访问、别人访问不了”——本机回环流量基本不受这条链路影响，出问题的就是入站那一侧。

另外有一个几乎所有版本都有的坑藏在“高级安全”面板的自定义设置里：三个配置文件各有一个“阻止所有入站连接”的复选框。一旦勾上，它会无视所有入站允许规则，全部拦掉。这个开关的优先级高于规则，排查时如果发现规则明明存在却不生效，先去看一眼这里有没有被勾上。我见过一次是某个“一键优化”工具顺手把它打开了，用户完全不知情。

2. 第一条规则怎么加：从弹窗放行到手动建规则的差别

理解了配置文件，就可以动手了。日常最高频的操作就是“让某个程序能对外提供服务”，而这件事有两条完全不同的路径：点弹窗放行，和手动建规则。两者生成的底层对象不一样，后续可维护性差得很远。

2.1 那个“允许访问”弹窗背着你做了什么

程序第一次尝试监听端口并接受外部连接时，Windows 会弹出一个“Windows Defender 防火墙已阻止此应用的部分功能”的对话框，下面列着专用网络和公用网络两个复选框。你点“允许访问”，系统会针对这个程序的可执行文件路径，在你勾选的每个配置文件下生成一条入站允许规则。

这个机制方便，但有几个隐性代价。

一是它只认路径。规则里的程序字段是%ProgramFiles%\SomeApp\app.exe这样的绝对路径，程序一升级、目录名里带版本号（Electron 打包的桌面应用尤其常见），路径就变了，旧规则永远匹配不上，新路径又会重新弹窗。时间一长，防火墙列表里堆一堆指向不存在路径的死规则。

二是它不限定作用域。弹窗放行生成的是“任何远程地址都可以连”的规则，等于把这个端口对整个网段甚至整个互联网敞开。放在家里无所谓，放在办公网里就不太合适了。

三是取消勾选不等于删除。在“允许应用通过防火墙”面板里把某个程序前面的勾去掉，规则通常只是被停用，对象还留在列表里。不同版本的行为略有差异，但一致的地方是：不要指望在面板里点几下就把规则清理干净，真正的清理要去wf.msc里做。

所以我的做法是：弹窗只在临时调试时点“允许”，正式部署一律手动建规则，并且建完立刻把弹窗生成的临时规则删掉，避免以后混淆。

2.2 手动建程序规则时的路径陷阱

手动建的入口是运行wf.msc打开“高级安全 Windows Defender 防火墙”，左侧选“入站规则”，右侧“新建规则”。选“程序”类型，然后填路径。

路径这里有几个反复出现的问题，值得单独说。

第一个是引号。路径里有空格时，在 netsh 命令行里必须用引号包起来，而且是整个program=参数值加引号，写法是program="C:\Program Files\My App\server.exe"。少一层引号就会解析失败，报错信息还不一定告诉你原因。

第二个是 32/64 位重定向。32 位程序访问System32时会被系统重定向到SysWOW64，规则里填的路径如果来源是程序自己上报的，可能和你以为的不一致。排查时用进程的实际映像路径为准，任务管理器里右键进程看“打开文件所在的位置”最靠谱。

第三个是服务与用户态程序的区别。如果放行对象是以 Windows 服务方式运行的进程，规则里可以额外用“服务”字段限定，只在该服务运行时生效，这比单靠路径精确得多。但要注意，很多系统服务共享svchost.exe这一个宿主，光凭路径根本区分不开是哪一项服务，这时候必须用服务限定，否则等于把整个svchost的所有实例都放行了，收敛性等于零。

第四个是程序更新导致的规则失效。这一点没什么好办法，只能靠命名规范来管理——规则名里带上程序名和端口，更新后对照着清理。下一节会讲命名。

还有一个不太被提起的点：程序规则不校验文件签名或哈希。也就是说，如果某人把一个同名文件放到同一路径，规则会照样放行。所以在对安全要求稍高的环境里，光靠程序规则是不够的，最好叠加端口和远程地址限定，形成“路径 + 端口 + 来源网段”的三重约束。

3. 端口、协议与作用域：把放行范围收到最小

程序规则解决“哪个程序能收包”，端口规则解决“哪个端口能收包”。实际部署里我更倾向用端口规则，因为它和程序解耦，程序换版本、换路径都不影响，而且天然能表达“只开放这一个口”的意图。

3.1 新建入站规则的四种类型怎么挑

“新建入站规则”向导里有四个选项：程序、端口、预定义、自定义。选哪个不是习惯问题，而是取决于你要表达什么约束。

• 程序：适合“只允许这一个可执行文件接收连接”，但如前所述，路径会漂移。
• 端口：适合“这个端口上的服务归我管”，是最常用的一种，配合协议（TCP/UDP）和本地端口号即可。
• 预定义：内置了一批常见角色，比如文件和打印机共享、远程桌面、核心网络。它的好处是系统知道这些角色需要哪些端口和程序，一次勾选全配齐；坏处是你不知道它到底开了几条规则、开了哪些端口。
• 自定义：前面几种的并集再加更多维度，比如同时限定程序、端口、服务、接口类型。

我的一般原则是：能用端口就不用预定义，因为预定义不透明；涉及系统内置角色时才用预定义，用完立刻去规则列表里看它到底生成了什么。

端口规则里有几个字段必须想清楚再填：

最后一行值得强调。很多人建规则时图省事把域、专用、公用全勾上，结果在酒店连 Wi-Fi 时这个端口照样对外开着。正确的做法是只勾专用（或只勾域），公用永远不勾。

3.2 远程地址限定，比改端口有用得多

我见过太多“把端口从 8080 改成 58080 图个安全”的操作。端口扫描一秒钟的事，改端口带来的收益接近于零，反而让文档和维护变复杂。真正有效的收敛手段是限定远程地址。

在规则的“作用域”页里，远程 IP 地址可以填单个地址、网段（CIDR 写法，比如192.168.10.0/24）或地址范围。填了之后，只有来自这些地址的连接才会匹配这条规则，其他来源一律按默认动作丢弃。这个约束是网络层的，扫描器扫到了端口也连不上，效果比改端口强得多。

举一个实际配置：某内部管理后台跑在 8080，只允许办公网段访问。规则这样写：

New-NetFirewallRule -DisplayName "Mgmt-Web-8080-In" ` -Direction Inbound -Protocol TCP -LocalPort 8080 ` -RemoteAddress 192.168.10.0/24,192.168.20.0/24 ` -Profile Private -Action Allow

两个网段用逗号分隔，配置文件只勾专用。这条规则的含义很清晰：只有这两个网段、且当前网络被判为专用时，才能连 8080。

作用域页里还有个“边缘遍历”选项，作用是允许来自 NAT 边缘设备的流量穿进来。默认是阻止，除非你明确知道自己在做什么，否则保持阻止。开了它等于给别人留了一条绕过地址限定的旁路。

另外提醒一句关于“本地 IP 地址”的用法：多网卡机器上（比如一台机器既有业务网卡又有管理网卡），可以用它把规则绑定到指定网卡对应的地址上，避免业务端口在管理网卡上也开着。这个字段在实际项目里用得不多，但遇到多网卡场景时是刚需。

4. 用命令行把重复工作干掉

图形界面适合学习和排查，不适合批量部署。三台以上机器要配同样的规则，就该上命令行了。Windows 这边有两套：老牌的netsh advfirewall，和 PowerShell 的NetSecurity模块。两套都能用，各有取舍。

4.1 netsh 的几条高频命令

netsh的优势是兼容性极好，从很老的版本到最新版命令基本没变，而且导出的.wfw文件可以整包迁移。缺点是语法偏“参数拼接”，出错提示不友好。

新建一条入站放行：

netsh advfirewall firewall add rule name="Mgmt-Web-8080-In" dir=in action=allow protocol=TCP localport=8080 remoteip=192.168.10.0/24 profile=private

删除同名规则：

netsh advfirewall firewall delete rule name="Mgmt-Web-8080-In"

查看所有入站规则（输出很长，建议重定向到文件再看）：

netsh advfirewall firewall show rule name=all dir=in > D:\fw-in.txt

改默认动作（谨慎，这会影响整机）：

netsh advfirewall set allprofiles firewallpolicy blockinbound,allowoutbound

开关某个配置文件：

netsh advfirewall set privateprofile state on netsh advfirewall set publicprofile state on

几个实战中总结的注意点：

name=参数是规则的显示名，同一方向下不能重名，重名会报错。也正因为如此，命名规范很重要，后面第 7 节会专门讲。

profile=的取值是domain、private、public、any。写any就等于三套策略全开，除非临时调试，别用。

remoteip=支持 CIDR，也支持逗号分隔的多个值，还支持localsubnet这种关键字。批量场景下用 CIDR 最清晰。

中文规则名在命令行里容易遇到编码问题，尤其是在不同代码页的机器之间复制粘贴命令时。我的做法是规则名一律用英文加连字符，中文只写在文档里，能省掉一大堆莫名其妙的乱码排查。

还有一点，netsh的部分子命令在 PowerShell 里直接跑会有解析差异，最保险的是在cmd里执行，或者在 PowerShell 里用cmd /c "netsh ..."包一层。这个坑我在早期脚本里踩过，同一条命令手工敲能跑、放进脚本就报参数错误，原因就是引号被 PowerShell 先吃掉了一层。

4.2 PowerShell 里的 New-NetFirewallRule 与批量导出导入

PowerShell 的NetSecurity模块是对象化的，规则是对象，可以管道、可以筛选、可以批量处理，适合做成配置即代码。同样的规则用 PowerShell 写：

New-NetFirewallRule -DisplayName "Mgmt-Web-8080-In" ` -Direction Inbound -Protocol TCP -LocalPort 8080 ` -RemoteAddress 192.168.10.0/24 ` -Profile Private -Action Allow ` -Group "Mgmt-Web" ` -Description "Internal mgmt console, office subnet only"

多出来的两个参数-Group和-Description很值得用。-Group会把规则归到一个组里，在wf.msc里能按组折叠显示，也方便一条命令批量删：

Remove-NetFirewallRule -Group "Mgmt-Web"

按条件查询当前都开了哪些端口，这一步在接手别人机器时特别有用：

Get-NetFirewallPortFilter | Where-Object { $_.LocalPort -eq "8080" } | Get-NetFirewallRule | Select-Object DisplayName, Direction, Action, Profile, Enabled

反向查“某个程序有没有被放行”：

Get-NetFirewallApplicationFilter | Where-Object { $_.Program -like "*server.exe" } | Get-NetFirewallRule | Format-Table DisplayName, Direction, Action, Enabled

导出这件事要分清楚两种“导出”，很多人在这里栽过跟头。

第一种是导出清单，用于审计和比对：

Get-NetFirewallRule | Select-Object DisplayName, Direction, Action, Profile, Enabled, Group | Export-Csv D:\fw-rules.csv -NoTypeInformation -Encoding UTF8

这个 CSV 只是给人看的，不能用来还原规则。它丢掉了端口、地址、程序这些关键字段，导入回去没有任何意义。

第二种是导出可还原的整包，用netsh的export：

netsh advfirewall export "D:\fw-backup\fw-20240101.wfw" netsh advfirewall import "D:\fw-backup\fw-20240101.wfw"

.wfw文件包含全部三个配置文件的所有规则和设置，import会整体覆盖当前配置，包括组策略下发的规则状态。所以导入前一定要先导出一份当前的，否则一旦覆盖就没法回退。这个操作我在测试机上做过一次，覆盖完发现远程管理端口也被一并冲掉，只能跑到机器跟前重配，教训很直接。

5. 规则不生效？按这套顺序查

规则加完连通了是常态，连不通才是日常。这时候最忌讳的是随机乱改——关防火墙试一下、改规则试一下、重启试一下，改到最后自己都不知道是哪一步起的作用。稳定做法是把排查拆成固定顺序，一层层往下走。

5.1 先开日志，让系统自己告诉你

Windows 防火墙默认不记录任何东西，所以你只能靠猜。第一步就是把丢包日志打开：

netsh advfirewall set allprofiles logging droppedconnections enable netsh advfirewall set allprofiles logging allowedconnections enable netsh advfirewall set allprofiles logging maxfilesize 8192 netsh advfirewall set allprofiles logging filename %systemroot%\system32\LogFiles\Firewall\pfirewall.log

droppedconnections是重点，它记录被丢弃的连接，格式大致如下：

2024-01-01 10:12:33 DROP TCP 192.168.10.55 192.168.10.20 51234 8080 60 - - - - - - - SEND

字段依次是时间、动作、协议、源地址、目的地址、源端口、目的端口。看一眼就能判断：包到没到、命中哪个端口、是被丢还是被放。

几个容易忽略的地方：

日志默认上限是 4096 KB，写满会滚动覆盖，如果排查时间跨度长，先把maxfilesize调大，不然关键记录可能已经被冲掉。

开了日志但文件里什么都没有，通常有两种可能：一是确实没有连接到达这台机器（问题在链路或服务监听地址上），二是日志开关只对某个配置文件生效而当前生效的是另一个。用allprofiles最省事。

日志里的DROP不一定是防火墙丢的，也可能是服务端主动断开后系统记录的状态。要结合端口和地址一起看，别看到一个 DROP 就认定是规则问题。

关日志的时候记得把droppedconnections关掉，长期开着在高流量机器上会明显增加磁盘写入。

5.2 冲突、优先级与被接管的三种典型情况

有了日志，就能往下定位了。我总结下来，规则“存在但不生效”基本落在三类里。

第一类是配置文件不匹配。规则只勾了专用，而当前网络是公用。这个用Get-NetConnectionProfile一眼就能看出来，前面讲过。修正方式要么改网络位置，要么给规则补上公用——但我更倾向改网络位置，因为给公用开端口本身就是风险。

第二类是显式阻止优先于允许。Windows 防火墙的匹配逻辑是：如果有一条阻止规则匹配上了这段流量，直接丢，不管有没有允许规则也匹配。所以当机器上存在一条范围很宽的阻止规则（比如某软件带的“阻止所有入站 TCP 8000-9000”），你新加的允许规则自然不起作用。排查办法是在规则列表里按端口筛选，把入站方向的阻止规则单独列出来看：

Get-NetFirewallPortFilter | Where-Object { $_.LocalPort -eq "8080" } | Get-NetFirewallRule | Where-Object { $_.Action -eq "Block" -and $_.Enabled -eq "True" } | Select-Object DisplayName, Profile, Direction

再往上还有一层：自定义设置里的“阻止所有入站连接”复选框，它比任何规则都优先。前面提过一次，这里再强调，因为它是那种“规则列表看起来一切正常、但就是不生效”的最常见原因。

第三类是策略被接管或覆盖。加域的机器上，组策略里有两个开关叫“应用本地防火墙规则”和“应用本地连接安全规则”。如果管理员把它们设成“否”，你在本地新建的规则会被完全忽略，wf.msc里照样显示着，但一点都不起作用。这种场景下你会看到规则存在、日志显示被丢，怎么改都没反应。确认的方法是看组策略结果：

gpresult /h D:\gp-report.html

打开生成的报告搜“防火墙”，能看到实际下发的策略值。修改需要联系域管理员，本地改不了。

另一种接管来自第三方安全软件。装完之后安全中心里会显示“由某安全软件管理”，此时 Windows 防火墙的开关会变灰，你以为在配置它，其实流量走的是另一套引擎。这类情况下要么在第三方软件里配，要么先卸载，别两头改。

排查顺序我固定成这几步，几乎能覆盖九成以上的问题：确认服务和监听地址 → 确认当前网络配置文件 → 看日志有没有 DROP → 查同端口的阻止规则 → 查自定义设置里的全局阻止 → 查组策略和第三方接管。按这个走，比随机试探省时间得多。

6. 几个容易翻车的实战场景

前面讲的是通用方法，这里挑几个我实际遇过、也见过别人反复卡住的具体场景展开。

6.1 共享与远程桌面：放行到什么程度算够

远程桌面和文件共享是两个最常被“顺手全开”的功能，也是最该收着用的。

远程桌面的端口是 TCP 3389。用预定义规则“远程桌面”一次能配齐，但它默认会把三个配置文件都勾上，公用下也开着。我的做法是：只保留专用（或只保留域），并且在作用域里把远程地址限定到管理网段。

New-NetFirewallRule -DisplayName "RDP-3389-In-OfficeOnly" ` -Direction Inbound -Protocol TCP -LocalPort 3389 ` -RemoteAddress 192.168.10.0/24 ` -Profile Domain -Action Allow

文件共享更麻烦，它不是一个端口，而是一组：TCP 445、TCP 139、UDP 137/138，外加“网络发现”依赖的一批。用预定义规则“文件和打印机共享”会一次开一串。这里的关键判断是：这台机器真的需要被别人通过 SMB 访问吗？如果只是自己要访问别人的共享，那根本不需要在这台机器上开入站规则——出站方向默认是放行的，直接就能连。这个区分很多人搞混，结果在自己的客户机上也把 445 敞开了。

一个实用的检查方法，看看当前 445 上有没有入站允许规则：

Get-NetFirewallPortFilter | Where-Object { $_.LocalPort -eq "445" } | Get-NetFirewallRule | Where-Object { $_.Direction -eq "Inbound" -and $_.Enabled -eq "True" } | Select-Object DisplayName, Action, Profile

如果机器不是文件服务器，这里应该是空的，或者只有域配置文件下的一条。公用配置文件下出现 445 的允许规则，基本可以判定是需要收敛的。

6.2 虚拟网卡、容器与本地回环

这一块是近年踩坑最密集的地方，因为虚拟化和容器在 Windows 上引入了大量额外的网络接口。

Hyper-V 会创建vEthernet系列虚拟网卡，WSL2 也会建一个vEthernet (WSL)。这些接口同样会被分配网络配置文件，同样受防火墙管。典型现象是：宿主机上的服务，从 WSL 里访问不通，但从局域网另一台机器访问得通。原因是 WSL 的虚拟网卡走的是另一条路径，规则的远程地址限定没把它包含进去。

解决办法不是把规则放开到“任何地址”，而是把 WSL 的网段加进远程地址列表。先用ipconfig或Get-NetIPAddress查一下虚拟网卡的地址段，再补进去：

New-NetFirewallRule -DisplayName "DevServer-3000-In" ` -Direction Inbound -Protocol TCP -LocalPort 3000 ` -RemoteAddress 192.168.10.0/24,172.20.0.0/16 ` -Profile Private -Action Allow

容器场景类似。以 WSL2 为后端的容器运行时，端口映射会经过一层转发，源地址可能被改写成虚拟网卡地址，你按“局域网网段”限定的规则就匹配不上。这时候要么把虚拟网段补进白名单，要么临时用一条更宽的规则做验证，确认是地址问题之后再收窄。

还有一个反直觉的现象：某些服务绑定在0.0.0.0上，本机用127.0.0.1访问不通，但用本机的局域网 IP 能通，或者反过来。这通常和服务的绑定地址以及 IPv6/IPv4 优先级有关，不完全是防火墙的锅，但排查时很容易被归到防火墙头上。判断方法是先把防火墙临时关掉试一次，如果现象不变，问题就在服务端绑定，不在防火墙。这条“先隔离变量”的习惯，比任何具体技巧都值钱。

7. 规则备份与长期维护

配好一次不难，难的是半年后还能说清楚每条规则是干什么的、能不能删。这部分讲讲怎么让配置活得久一点。

7.1 导出导入与版本留档

.wfw整包导出是唯一的可靠备份方式，前面提过语法。我的习惯是在几个固定节点各导一份：初始配置完成后、每次批量变更前、每次系统大版本升级前。文件名带上日期和用途，比如fw-20240101-baseline.wfw、fw-20240315-before-update.wfw，放在一个不受系统盘重装影响的目录里。

导入要格外小心，因为它整体覆盖。标准动作是三步：先导出当前的做回退点，再导入目标文件，最后立刻验证关键端口是否可达。第三步经常被跳过，结果导入完以为完事了，实际远程管理端口被冲掉，人已经被关在门外。

除了整包，我还会额外留一份“人类可读”的清单，就是前面提到的 CSV 导出。它的作用不是还原，而是比对——两次变更之间导一份，用文本比对工具 diff 一下，能清楚看到多了哪几条、少了哪几条。这个做法在多人协作的机器上尤其有用，能快速定位“是谁在什么时候加了一条奇怪的规则”。

7.2 给规则起名字这件事，值得认真对待

最后说一个看起来很小、实际影响很大的事：命名。

我接手过的机器里，规则列表最乱的一台有三百多条规则，名字全是Rule 1、新建入站规则、New Rule 2这种。想找一条和 8080 有关的规则，只能靠端口筛选一条条翻。反过来，命名规范的机器，看列表就知道全貌。

我现在用的格式是三段式：用途-端口-方向，比如Mgmt-Web-8080-In、RDP-3389-In-OfficeOnly、Backup-Agent-9100-Out。全英文、连字符分隔、不含空格。好处是命令行里不用加引号，脚本里不会因为空格断词，跨语言环境也不会有编码问题。

配套的是分组。给同一批规则加同一个-Group，比如都归到Mgmt-Web下，删除时一条Remove-NetFirewallRule -Group "Mgmt-Web"就干净了，不用逐条点名。这个习惯在临时环境和测试机上特别省事。

还有一条经验：定期清理指向不存在路径的程序规则。这些规则不会有任何作用，但会干扰判断——你看到 8080 有一条允许规则，以为是它放行的，实际生效的是另一条。清理方法是用 PowerShell 把程序规则拉出来，逐个检查路径是否存在：

Get-NetFirewallApplicationFilter | ForEach-Object { $prog = $_.Program if ($prog -and $prog -notlike "*%*" -and -not (Test-Path $prog)) { [PSCustomObject]@{ Program = $prog; RuleId = $_.InstanceID } } }

输出里带%的是用了环境变量的路径，Test-Path直接判会有误报，所以先排除掉，手动确认。

我个人在实际操作中的体会是，防火墙这件事的难点从来不在“会不会点那个新建规则按钮”，而在于能不能说清楚每一条规则为什么存在。一条规则如果讲不出它服务的对象、访问来源和生效范围，那它大概率是历史遗留，该被清理。把命名、分组、导出这三件小事坚持下来，半年后的自己会感谢现在的自己。