“Windows防火墙”这四个字大多数人第一次真正注意到它是在某个下午——程序明明启动了、端口也监听着外面就是连不进来。我印象最深的一次是几年前把一个内部小工具从开发机搬到另一台机器上进程活得好好的本机curl打得通局域网里另一台机器死活超时。查了快两个小时最后发现那台机器的网络位置被判成了“公用”公用配置文件下压根没有对应的入站放行规则而开发机上我早就在弹窗里随手点过“允许访问”。从那以后我就养成一个习惯任何要对外服务的东西上线之前先把防火墙规则一条条写清楚而不是等出问题再回头翻。这篇就把这个习惯拆开讲。从“它到底在拦什么”入手讲清三种网络配置文件的关系再讲第一条规则怎么加、端口和协议怎么选、作用域怎么收敛然后是命令行和 PowerShell 的批量玩法、日志怎么开、规则不生效按什么顺序查最后聊几个我自己踩过、也见过别人反复踩的场景。零基础可以顺着读做过几年运维的可以直接跳到第三节往后找能抄的东西。1. 三种网络配置文件同一台机器上的三套独立策略先把最容易被忽略的一层讲清楚。Windows 防火墙不是“一个开关”而是三套互相独立、各自带开关和规则集的策略分别在域Domain、专用Private、公用Public三个配置文件下生效。同一时刻机器上只有一套策略在起作用具体是哪套由系统根据当前网络连接的位置判定。1.1 域、专用、公用到底按什么判定判定逻辑不是让你手选的而是由网络位置感知NLA先做一轮判断再允许你在设置里改。加入域的机器能联系到域控制器时网络自动归为“域”除此之外你第一次连接某个网络时系统会弹一个小面板问你“是否允许此电脑被此网络上的其他电脑发现”选“是”通常归为专用选“否”归为公用。这个初判的依据是网络本身的一些特征比如网关 MAC、是否被标记为共享网络等。三者的典型使用场景和默认宽松度差别很大我用一张表说明配置文件典型场景默认发现能力常见误判域加域办公机、连内网域控可被域内设备发现出差脱离域后仍残留域策略专用家庭网络、可信内网可被局域网发现开放共享家用路由器换了之后仍保持专用公用咖啡店、酒店、机场隐藏本机几乎全拦入站内网 IP 段被判成公用服务连不上最容易出问题的就是最后一行。很多公司内网用的地址段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参数值加引号写法是programC:\Program Files\My App\server.exe。少一层引号就会解析失败报错信息还不一定告诉你原因。第二个是 32/64 位重定向。32 位程序访问System32时会被系统重定向到SysWOW64规则里填的路径如果来源是程序自己上报的可能和你以为的不一致。排查时用进程的实际映像路径为准任务管理器里右键进程看“打开文件所在的位置”最靠谱。第三个是服务与用户态程序的区别。如果放行对象是以 Windows 服务方式运行的进程规则里可以额外用“服务”字段限定只在该服务运行时生效这比单靠路径精确得多。但要注意很多系统服务共享svchost.exe这一个宿主光凭路径根本区分不开是哪一项服务这时候必须用服务限定否则等于把整个svchost的所有实例都放行了收敛性等于零。第四个是程序更新导致的规则失效。这一点没什么好办法只能靠命名规范来管理——规则名里带上程序名和端口更新后对照着清理。下一节会讲命名。还有一个不太被提起的点程序规则不校验文件签名或哈希。也就是说如果某人把一个同名文件放到同一路径规则会照样放行。所以在对安全要求稍高的环境里光靠程序规则是不够的最好叠加端口和远程地址限定形成“路径 端口 来源网段”的三重约束。3. 端口、协议与作用域把放行范围收到最小程序规则解决“哪个程序能收包”端口规则解决“哪个端口能收包”。实际部署里我更倾向用端口规则因为它和程序解耦程序换版本、换路径都不影响而且天然能表达“只开放这一个口”的意图。3.1 新建入站规则的四种类型怎么挑“新建入站规则”向导里有四个选项程序、端口、预定义、自定义。选哪个不是习惯问题而是取决于你要表达什么约束。程序适合“只允许这一个可执行文件接收连接”但如前所述路径会漂移。端口适合“这个端口上的服务归我管”是最常用的一种配合协议TCP/UDP和本地端口号即可。预定义内置了一批常见角色比如文件和打印机共享、远程桌面、核心网络。它的好处是系统知道这些角色需要哪些端口和程序一次勾选全配齐坏处是你不知道它到底开了几条规则、开了哪些端口。自定义前面几种的并集再加更多维度比如同时限定程序、端口、服务、接口类型。我的一般原则是能用端口就不用预定义因为预定义不透明涉及系统内置角色时才用预定义用完立刻去规则列表里看它到底生成了什么。端口规则里有几个字段必须想清楚再填字段取值建议说明协议TCP 或 UDP别选“任何”选任何等于两个协议都放范围翻倍本地端口具体端口避免范围范围写法8000-8100会一次性开 101 个口远程端口入站规则里一般不填入站方向远程端口是随机的填了反而匹配不上配置文件只勾实际需要的三项全勾等于三套策略都开公用下也开着最后一行值得强调。很多人建规则时图省事把域、专用、公用全勾上结果在酒店连 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 nameMgmt-Web-8080-In dirin actionallow protocolTCP localport8080 remoteip192.168.10.0/24 profileprivate删除同名规则netsh advfirewall firewall delete rule nameMgmt-Web-8080-In查看所有入站规则输出很长建议重定向到文件再看netsh advfirewall firewall show rule nameall dirin 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的exportnetsh 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.logdroppedconnections是重点它记录被丢弃的连接格式大致如下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直接判会有误报所以先排除掉手动确认。我个人在实际操作中的体会是防火墙这件事的难点从来不在“会不会点那个新建规则按钮”而在于能不能说清楚每一条规则为什么存在。一条规则如果讲不出它服务的对象、访问来源和生效范围那它大概率是历史遗留该被清理。把命名、分组、导出这三件小事坚持下来半年后的自己会感谢现在的自己。
