Windows 防火墙与业务应用 ── 入站规则要通过安装程序注册

「在开发机上明明运行正常，装到客户现场后客户端却连不上服务器」「首次启动时好像弹出了什么警告，现场人员似乎点了取消」「用 netstat 看端口明明在监听，隔壁电脑却连不进来」── 在业务应用的部署现场，这类「无法通信」的报修可以说是老生常谈中的老生常谈。而始终高居原因榜首的，正是Windows 防火墙（Windows Defender Firewall）。

麻烦的地方在于，问题在开发机上根本看不出来。开发者在 Visual Studio 调试运行时往往会自己点掉允许提示，或者本身就以管理员身份操作，因此在完全没有察觉默认入站阻止的情况下就把应用发布出去了。而在客户现场，实际操作电脑的是没有管理员权限的普通用户，网络还由 GPO 集中管理。与其说是「本该能用的东西却用不了」，不如说事实是「开发机只是碰巧能用」。

本文面向自研业务应用时会遇到「客户现场无法通信」问题的应用开发者，以及负责接收此类咨询的中小企业信息系统部门人员，在最低限度掌握 Windows 防火墙的默认行为与配置文件机制的基础上，基于截至 2026 年 8 月的一手资料，系统整理入站规则的设计、通过安装程序完成注册的实务、故障排查步骤，直至 GPO/Intune 集中管理下的注意事项。

1. 先说结论

• Windows 防火墙的默认行为是「入站阻止，出站允许」。只要不是对请求的响应，入站流量在没有匹配规则的情况下都会被丢弃。¹
• 只有监听端口的服务器型应用才需要入站规则。只主动发起连接的客户端应用，在默认状态下就能正常通信。请首先从这一点入手进行判断。¹
• 配置文件共有 3 种（域/专用/公用）。「域」会在检测到域控制器时自动应用，「公用」是未识别网络的默认值。规则以配置文件为单位决定是否生效。¹
• 绝不能把生产环境交给那个「重要警告」对话框处理。管理员点击取消会生成阻止规则，而没有管理员权限的用户无论点击哪个按钮都会生成阻止规则。在删除已生成的规则之前，对话框不会再次出现。²
• 结论是「业务应用的入站规则应通过安装程序注册」。Microsoft 官方也建议在应用首次启动之前就部署好规则，并禁用入站通知。²
• 规则应按最小权限原则设计。以「程序 + 协议 + 端口」为核心，将配置文件限定为域/专用，并把远程 IP 限制在必要的子网范围内。程序路径不支持使用通配符。²³
• 排查顺序为 Test-NetConnection → Get-NetFirewallRule → pfirewall.log。防火墙日志默认不会写入，只有启用「记录被丢弃的数据包」后才会生成。⁴⁵⁶
• 通过停止服务来整体禁用防火墙不受支持。在 GPO/Intune 集中管理下，「本地规则合并」有可能被禁用，此时本地规则不会生效，需要向信息系统部门申请集中分发规则。¹²

2. 准确把握默认行为 ── 入站默认阻止，出站默认允许

首先准确打好基础。Windows 防火墙在所有版本中都默认启用，是一种主机型防火墙，其默认行为可以归结为以下两行。¹

• 入站（inbound）：除非是对请求的响应（solicited），或与规则匹配，否则全部阻止
• 出站（outbound）：除非与规则匹配，否则全部允许

从这两行行为可以得出对业务应用而言最重要的判断依据：只有「监听方」才需要入站规则。

• 只主动连接公司内部 Web 服务器・数据库服务器・核心系统的客户端应用 → 原则上不需要规则。连接的返回数据包属于「对请求的响应」，因此默认就能通过。
• 通过 TCP、gRPC 或自定义协议等开放端口等待接受连接的服务器型应用・Windows 服务 → 必须配置入站规则。
• 另外，从远程使用命名管道的架构属于例外。远程命名管道并不经过应用自身的端口，而是通过 SMB（TCP 445）通信，因此需要的不是应用自身的规则，而是文件共享（SMB）一侧的规则。
• 还有一种例外，是把出站默认行为明确改为阻止的高安全环境。这种配置只存在于部分组织，一旦采用，客户端应用也需要申请出站规则。²

flowchart TB
    APP["梳理自研应用的通信方式"] --> Q{"是否开放端口<br/>等待接受连接"}
    Q -- "不等待连接<br/>(仅作为客户端发起连接)" --> C1["入站规则原则上不需要<br/>连接的返回作为「响应」通过"]
    Q -- "等待连接<br/>(服务器型・接收回调)" --> S1["入站规则为必需<br/>→ 通过安装程序注册 - 见第5节"]
    C1 -.-> EX["例外－出站默认阻止的<br/>高安全环境需申请出站规则"]

「原本以为只是客户端的应用，实际上也在监听」这类情况（接收结果回调、作为其他进程的通知接收端等）很容易被忽视。如果不清楚自研应用具体通过哪种通信方式进行监听，建议在设计阶段一并确认《Windows 的进程间通信该怎么选 ── 命名管道 / TCP / gRPC / 共享内存 / COM 判断表》。

2.1. 配置文件与「网络位置」

规则以网络配置文件为单位应用。配置文件共有 3 种。¹

当前生效的配置文件可以用 Get-NetConnectionProfile 确认，专用/公用之间的切换则通过 Set-NetConnectionProfile 进行。¹ 现场常见的事故是：客户现场的 workgroup 环境中网络被判定为「公用」，导致仅限域/专用配置文件生效的入站规则没有被应用。当出现「明明有规则却不通」的情况时，请先怀疑配置文件是否匹配，而不是先去检查规则内容本身。

2.2. 规则的优先级

当存在多条规则时，其评估方式并不是按权重排序的列表，而是由以下这套一致的原则决定的。²

1. 显式的允许规则优先于默认阻止
2. 显式的阻止规则优先于与之冲突的允许规则
3. 在不违反上述第 2 条的前提下，越具体的规则优先级越高

这在实务上的含义是：「只要存在一条阻止规则，之后无论追加多少条允许规则都无法胜过它」。正如下一章将看到的，恰恰就是那个对话框会悄悄地创建出这样的阻止规则。

3. 「重要警告」对话框的真面目 ── 为什么不能把生产环境交给它

当应用首次开始监听（listen）端口时，如果既没有针对该应用的允许规则，也没有管理员定义的规则，Windows 就会显示那个常见的「Windows 安全中心的重要警告」对话框，内容是「此应用的部分功能已被 Windows Defender 防火墙阻止」。其行为规范是明确的。²

• 显示给拥有管理员权限的用户时：点击「允许访问」会生成允许规则。但点击「取消」则会生成阻止规则，通常是 TCP 用与 UDP 用各一条，共两条。
• 显示给没有管理员权限的用户时：无论选择哪个选项都会生成阻止规则。
• 无论哪种情况，只要不删除已生成的规则，对话框就不会再次显示，通信会持续被阻止。

flowchart TB
    L["应用开始监听端口"] --> Q1{"是否存在与该应用<br/>匹配的规则"}
    Q1 -- "是" --> R1["遵循规则<br/>－不显示对话框"]
    Q1 -- "否" --> Q2{"入站通知是否<br/>已启用"}
    Q2 -- "禁用" --> R2["静默阻止<br/>－不会创建规则"]
    Q2 -- "启用" --> DLG["「重要警告」对话框"]
    DLG -- "管理员选择「允许访问」" --> OK["会创建允许规则"]
    DLG -- "管理员选择「取消」" --> NG1["会创建阻止规则"]
    DLG -- "没有管理员权限的用户<br/>(无论选择哪个操作)" --> NG2["会创建阻止规则"]
    NG1 --> NEVER["在删除规则之前<br/>对话框不会再次出现"]
    NG2 --> NEVER

也就是说，这个对话框表面上看是「向用户征求许可的机制」，但在业务应用的现场，实际上却成了「普通用户一旦碰到就会烙下阻止规则的机制」。如果实施人员以管理员账户首次启动并在对话框中点击了允许，生成的允许规则会对整台电脑生效，因此从第二天起普通用户暂时也能正常通信。即便如此，事故隐患依然存在 ── 例如普通用户第一次触发了部署验证时没有走到的监听路径时、当前生效的网络配置文件与部署时不同时，以及更新导致 exe 路径发生变化时（第 4、5 节）。

对于由非管理员使用的设备，Microsoft 官方也明确给出了以下最佳实践。²

1. 在应用首次启动之前，预先部署好所需的规则（通过安装程序或管理端分发）
2. 禁用入站通知（关闭通知后，运行时自动创建规则这件事本身就不会发生）

禁用通知可以通过 Set-NetFirewallProfile -NotifyOnListen False，或通过组策略进行设置。⁷ 「对话框弹出后就让现场人员点允许」并不是一种运维流程，而是在预约事故的发生。入站规则应在安装时注册 ── 这正是本文的结论，也与 Microsoft 的推荐一致。

4. 入站规则的设计 ── 按程序指定・按端口指定・按服务指定

接下来设计要注册的规则内容。指定方式大体分为 3 类，需要判断是单独使用还是组合使用。

在此基础上，还要进一步收窄适用范围。Microsoft 官方的设计建议也是「入站规则应尽可能具体」。²

• 限定配置文件：仅在公司内部使用的业务应用，其入站规则应限定为域/专用，不要在公用配置文件中启用。这样可以防止笔记本电脑一连上公司外部的 Wi-Fi，监听端口就瞬间向全世界开放这种事故。
• 限定远程 IP：如果连接来源是确定的，就把 -RemoteAddress 限制在该子网范围内。对于家庭・小型网络，官方推荐使用 LocalSubnet 关键字进行限定。²³
• 方向与条数：如果监听只使用 TCP，那么一条 TCP 规则就足够了。不要图省事，像对话框自动生成的那样同时创建 TCP 和 UDP 两条规则。

「只允许必要的对象、访问必要的端口、连接必要的程序」── 入站规则的设计，归根结底就是这一句最小权限原则。

5. 通过安装程序注册的实务 ── netsh 与 New-NetFirewallRule

5.1. 前提：需要管理员权限

添加・删除防火墙规则属于对整台电脑的设置变更，因此必须以管理员权限（提升的进程）执行。⁸ 安装程序通常本身就是以管理员权限运行的，因此把规则注册放进安装流程中是合理的做法。这并不能成为让应用本体以管理员身份运行的理由。关于这条界线的思路，在《Windows 什么时候需要管理员权限 - UAC、保护区域与设计上的辨别方式》中有详细讨论。

5.2. 通过 netsh advfirewall 注册

虽然是比较传统的方式，但 netsh advfirewall firewall add rule 的优点是几乎可以从任何安装程序中方便地调用。⁸

rem add rule 即使已存在同名规则也会继续追加，为了应对重新安装・修复・
rem 更新时的重复执行，需要先删除同名规则再重新注册
netsh advfirewall firewall delete rule name="MyCompany OrderServer"

rem 按程序指定+端口指定+配置文件限定的入站允许规则
netsh advfirewall firewall add rule name="MyCompany OrderServer" dir=in action=allow program="C:\Program Files\MyCompany\OrderServer\OrderServer.exe" protocol=TCP localport=50051 profile=domain enable=yes

rem 卸载时：按名称删除
netsh advfirewall firewall delete rule name="MyCompany OrderServer"

add rule 不会替换已存在的同名规则，而是以相同名称继续追加，因此如果不先执行 delete rule，规则就会随着每次重新执行不断增殖，即使在更新后更改了路径或范围，旧的允许规则也会继续残留（首次执行时开头的 delete rule 会返回「没有匹配的规则」之类的提示，但批处理会继续执行下去，因此这样的顺序没有问题；如果安装程序是通过退出代码判断成败的，请以末尾的 add rule 的结果为准）。也可以像 remoteip=157.60.0.1,172.16.0.0/16,LocalSubnet 这样限定连接来源。⁸ 由于删除操作会把名称匹配的规则一并清除，规则名建议加上自家公司前缀以保持唯一，这样比较安全。

5.3. 通过 PowerShell（New-NetFirewallRule）注册

如果需要更精细的控制，可以使用 NetSecurity 模块。-DisplayName 是必填参数，-Profile 可以用逗号分隔（不含空格）指定多个值。³

# 注册(从安装程序以提升权限执行)。由于 -Name 是唯一标识符，
# 在重新安装・修复・更新时重复执行会因同名规则已存在而报错，
# 因此采用先删除已有同名规则再重新创建的方式来实现幂等
Remove-NetFirewallRule -Name "MyCompany-OrderServer-In" -ErrorAction SilentlyContinue
New-NetFirewallRule -Name "MyCompany-OrderServer-In" `
    -DisplayName "MyCompany OrderServer (TCP 50051 入站)" `
    -Direction Inbound -Action Allow `
    -Program "C:\Program Files\MyCompany\OrderServer\OrderServer.exe" `
    -Protocol TCP -LocalPort 50051 `
    -Profile Domain,Private -RemoteAddress LocalSubnet

# 卸载时：即使规则不存在也不报错
Remove-NetFirewallRule -Name "MyCompany-OrderServer-In" -ErrorAction SilentlyContinue

这里明确指定 -Name 是有原因的。-Name 是规则的唯一标识符，省略时会被分配一个随机值。由于显示名（-DisplayName）会因语言环境不同而变化，Microsoft 官方指南建议在脚本中用 -Name 作为定位规则的键。³ 为了让卸载程序能够确实只删除自己创建的规则，固定 -Name 也应视为必要项。

5.4. 更新导致 exe 路径发生变化的情况

按程序指定的规则是以完整路径固定对象的。也就是说，一旦更新改变了安装位置或 exe 名称，规则虽然还在，却会找不到对象，监听会再次被阻止。此时，位于新路径下的 exe 会被当作「没有规则的应用」处理，如果所在环境启用了通知，第 3 章介绍的对话框就会再次出现，普通用户一操作就会烙下阻止规则；如果按照第 3 章的建议禁用了通知，那么连对话框都不会出现，就直接静默失败了。部署到带版本号的文件夹这种方式，以及部署路径会随自更新而变动的方式，尤其容易发生这类事故。

flowchart TB
    V1["导入 v1.0<br/>规则指向 v1.0 文件夹中的 exe"] --> UP["更新后部署到 v1.1 文件夹<br/>实际运行的 exe 路径发生变化"]
    UP --> MISS["旧路径的规则找不到对象<br/>－规则仍在但已不生效"]
    MISS --> Q{"入站通知是否<br/>已启用"}
    Q -- "启用" --> DLG["对话框再次出现<br/>普通用户一旦操作就会生成阻止规则"]
    Q -- "禁用" --> SILENT["对话框也不出现<br/>直接静默阻止"]
    MISS -.->|"应对"| FIX["让路径在更新前后保持固定<br/>或在更新流程中删除旧规则并重新注册"]

对策很简单，二选一即可。

• 固定安装位置，使exe 的完整路径在跨越更新前后都保持不变
• 如果更新会改变路径，则让更新程序删除旧规则并以新路径重新注册（在更新流程中同样执行 5.2／5.3 节的命令）

如果是 MSI，通常的做法是把规则注册作为文件部署完成后执行的自定义操作（卸载时则是对应的删除自定义操作）嵌入进去。WiX 等工具集也提供了以声明式方式描述防火墙规则的扩展。具体实现位置会因所选的发布方式而不同，请一并参考《Windows 应用发布方式怎么选 - MSI / MSIX / ClickOnce / xcopy / 自定义 updater 判断指南》。另外，客户现场部署时另一个常见麻烦——杀毒软件误报的问题，则在《当自研 Windows 应用被 Microsoft Defender 判定为病毒 ── 误报处理与性能影响应对指南》中有详细说明。

6. 故障排查 ── 「无法通信」的排查流程

先把接到报修时应遵循的步骤顺序固定下来。整体流程如下。

flowchart TB
    S["「客户端无法通信」"] --> N["服务器端 - netstat -ano"]
    N -- "未处于监听状态" --> APP["防火墙之前的问题<br/>调查应用・服务端"]
    N -- "处于 LISTENING 状态" --> T["客户端 - Test-NetConnection"]
    T -- "TcpTestSucceeded=True" --> OTHER["可达性正常<br/>调查应用层－认证・协议"]
    T -- "False" --> P["服务器端 - Get-NetConnectionProfile<br/>确认当前生效的配置文件"]
    P -- "与规则的对象不一致" --> FIXP["重新检查规则的配置文件指定"]
    P -- "一致" --> R["Get-NetFirewallRule -PolicyStore ActiveStore<br/>确认是否存在允许规则・是否混入了阻止规则"]
    R --> LOGCHK["在 pfirewall.log 中确认丢弃 DROP 记录"]

关于第 4 步的补充说明：端口与程序等条件并不在规则本体上，而是在过滤器对象一侧，因此要从端口反查规则，需要通过过滤器进行查询。⁵⁷

# 反查与端口 50051 相关的规则
Get-NetFirewallPortFilter | Where-Object { $_.LocalPort -eq 50051 } | Get-NetFirewallRule

# 追踪规则的来源(本地还是 GPO)
Get-NetFirewallRule -PolicyStore ActiveStore -TracePolicyStore |
    Select-Object Name, DisplayName, PolicyStoreSourceType, PolicyStoreSource

第 5 步中的防火墙日志（pfirewall.log）默认不会记录任何内容。默认路径为 %windir%\system32\logfiles\firewall\pfirewall.log，默认最大大小为 4,096KB，只有启用「将丢弃的数据包记录到日志」或「将成功的连接记录到日志」二者之一后，才会开始写入。⁶ 如果是单台机器，可以用下面的命令启用。⁶

netsh advfirewall set allprofiles logging droppedconnections enable
netsh advfirewall set allprofiles logging allowedconnections enable

日志是文本文件，会逐行记录是丢弃（DROP）还是允许（ALLOW）、协议、源/目标 IP 与端口，因此可以据此确定「客户端发来的 SYN 是到达后被丢弃，还是根本没有到达」。另外，在通过策略配置日志的环境中，有时会因为日志文件夹缺少写入权限（服务 mpssvc 的 FullControl）而无法创建日志文件，此时需要手动创建文件夹并授予相应的 ACL。⁶

如果要进一步深入排查，启用审核策略「筛选平台数据包丢弃」后，每次丢弃都会记录安全事件 5152。不过由于事件数量非常庞大，Microsoft 建议改用以连接为单位记录的事件 5157（筛选平台连接）。这是一种仅在排查期间临时启用、而非长期开启的工具。⁹

最后，需要明确指出不该采用的排查方式。通过停止防火墙服务（MpsSvc）来整体禁用防火墙不受支持，会引发开始菜单无法使用、应用商店更新失败等操作系统层面的问题。如果无论如何都需要禁用来做确认，正确做法是在保持服务运行的状态下，用 Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False 禁用配置文件，确认完毕后立即改回。¹⁷ 而且，一旦确定原因就是防火墙，正确的应对方式并不是把禁用状态永久化，而是补上一条正确的规则。

7. 组织集中管理下的注意事项 ── 本地规则不生效的环境与申请方法

即使通过安装程序注册了规则，也存在这条规则不会生效的环境。在通过 GPO 或 Intune（CSP）集中管理防火墙的组织中，可以按配置文件逐一禁用「本地规则合并」（AllowLocalPolicyMerge）。一旦该设置被禁用，本地管理员（包括安装程序）创建的规则就不会被应用，需要入站连接的应用的规则就必须改为从 GPO/CSP 集中分发。²

flowchart TB
    GPOR["通过 GPO/Intune 分发的规则"] --> EFF["实际生效的规则集合<br/>－ActiveStore"]
    LOCAL["本地创建的规则<br/>－包含安装程序注册的规则"] --> Q{"本地规则合并<br/>－AllowLocalPolicyMerge"}
    Q -- "启用(默认)" --> EFF
    Q -- "禁用" --> DROP["规则虽然存在但不会被应用<br/>→ 改为通过 GPO/CSP 集中分发"]

作为开发方・实施方，现实中可以采取以下应对措施。

• 把安装程序的规则注册设计成「不会失败」的形式（注册操作本身会成功，因此无法通过错误来检测这种情况，需要把部署后的连通性验证纳入流程）
• 用第 6 章步骤 4 中的 -TracePolicyStore 确认生效规则的来源究竟是本地还是 GPO⁵
• 一旦确认属于本地规则不生效的环境，就改为向信息系统部门提出规则分发申请

申请时应把以下信息整套一并提交。防火墙规则必须集齐方向・程序・端口・范围才能创建，因此这份信息本身就相当于一份「业务应用的网络规格说明书」。

从信息系统部门的角度来看，有没有这张表格的申请，工作量也完全不同。反过来，只给出端口号的「请帮忙开一下」这种申请，正如第 4 章所述，很容易变成过度授权。另外，域环境下文件共享・认证相关的通信要求，也在随着防火墙之外的其他强化措施（如强制启用签名等）而变化，请一并参考《SMB 签名与 LDAP 通道绑定 ── 用实务收尾 NTLM 对策的「剩余一半」》。

8. 总结

• Windows 防火墙的默认行为是入站阻止、出站允许。只有需要监听的服务器型应用才需要入站规则，仅作为客户端发起连接的应用原则上不需要。
• 规则以配置文件（域/专用/公用）为单位应用。「明明有规则却不通」时，第一嫌疑对象就是配置文件不匹配。
• 「重要警告」对话框会因取消操作或无权限用户的操作而生成阻止规则，之后就不会再次显示。绝不能把生产环境的运维交给这个对话框来处理。
• 业务应用的入站规则应通过安装程序注册 ── 这是唯一的原则。注册需要在管理员权限下进行，并且从注册到删除都应固定使用 -Name 来实现。
• 规则应以程序 + 协议 + 端口为核心，再通过配置文件和远程 IP 进一步收窄范围。如果更新会改变 exe 路径，请不要忘记重新注册规则。
• 排查应按 netstat → Test-NetConnection → 确认配置文件 → Get-NetFirewallRule（ActiveStore） → pfirewall.log 的顺序机械化地进行。通过停止服务来禁用防火墙不受支持。
• 在 GPO/Intune 集中管理下，本地规则合并有可能被禁用。此时应备齐规则名・方向・程序・端口・远程 IP・配置文件等信息，向信息系统部门申请分发。

相关文章

• Windows 的进程间通信该怎么选 ── 命名管道 / TCP / gRPC / 共享内存 / COM 判断表
• Windows 应用发布方式怎么选 - MSI / MSIX / ClickOnce / xcopy / 自定义 updater 判断指南
• Windows 什么时候需要管理员权限 - UAC、保护区域与设计上的辨别方式
• 当自研 Windows 应用被 Microsoft Defender 判定为病毒 ── 误报处理与性能影响应对指南
• SMB 签名与 LDAP 通道绑定 ── 用实务收紧 NTLM 对策的「另一半」
• Windows 服务的创建与运维 ── 从任务计划程序的取舍到 BackgroundService 服务化

相关咨询领域

合同会社小村软件承接服务器型业务应用的安装程序设计（包括防火墙规则的注册与删除）、客户现场「无法通信」的原因调查，以及面向 GPO 管理下部署的网络需求梳理。即使只是想先从「开发机上能用，客户现场却不能用」的排查开始也没有关系。

• Windows应用开发
• 故障调查・原因分析
• 技术咨询・设计评审
• 联系我们

参考链接

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

相关主题

与本文相近的主题页面。以本文为起点，可以进一步了解相关服务和其他文章。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

常见问题

汇总了咨询这一主题时常见的问题。

只作为客户端连接服务器的应用，也需要防火墙规则吗？

原则上不需要。由于 Windows 防火墙的默认行为是「入站阻止、出站允许」，因此只主动发起连接的客户端应用在默认状态下就能正常通信。只有开放端口等待接受连接的一方，也就是服务器型应用，才需要入站规则。不过有两个例外：一是在高安全环境中，出站有时也会被改为默认阻止，此时需要申请出站规则；二是即使是客户端应用，如果设计上会自行监听端口作为结果通知的接收端，那部分功能就需要入站规则。

在「Windows 安全中心的重要警告」对话框中点击「允许访问」不就可以了吗？

当场是能解决，但不能把生产环境的运维交给它。这个对话框在拥有管理员权限的用户点击取消时会生成阻止规则；而对于没有管理员权限的用户，无论点击哪个按钮都会生成阻止规则。一旦生成了规则，在被删除之前对话框就不会再次显示，通信也会持续失败。在实际操作电脑的是普通用户的业务应用场景中，很容易出现「只要有人点过一次取消，此后就一直无法通信」的状况。Microsoft 也建议在应用首次启动之前就预先部署好规则。

入站规则应该按端口指定，还是按程序指定来创建？

基本原则是组合使用，而不是单独使用。按程序指定可以用 exe 的完整路径来限定对象，但更新导致路径变化时规则就会找不到对象（且不支持通配符）。按端口指定能让向信息系统部门的申请更加明确，但同一端口上监听的其他进程也会被一并放行。生产环境的业务应用，最小权限的基本形态是以「程序 + 协议 + 端口」为核心，将配置文件限定为域/专用，并把远程 IP 限制在客户端所在的子网范围内。只有在端口是动态的情况下，才单独使用按程序指定。

安装程序注册的规则，在客户的电脑上似乎没有生效，这是为什么？

很可能是因为客户现场的防火墙由 GPO 或 Intune 集中管理，「本地规则合并」（AllowLocalPolicyMerge）被禁用了。这项设置一旦被禁用，本地创建的规则即使在配置文件上存在，也不会被应用，规则就只能改为从 GPO/CSP 一侧集中分发。请用 Get-NetFirewallRule -PolicyStore ActiveStore 确认当前生效的全部规则，并向信息系统部门申请规则分发。申请时把规则名・方向・程序路径・协议与端口・远程 IP 范围・配置文件一并备齐提交，通常一次就能通过。

为了排查通信问题，可以临时禁用防火墙吗？

务必避免通过停止服务（MpsSvc）来禁用防火墙。这是 Microsoft 不支持的操作，会引发开始菜单无法使用、应用商店更新失败等操作系统层面的问题。如果无论如何都想通过禁用来排查，正确做法是在保持服务运行的状态下，用 Set-NetFirewallProfile -Enabled False 禁用配置文件。不过即便如此，也应仅限于用几分钟时间确认「原因是否在于防火墙」这一用途，确认完毕后应立即改回。让防火墙保持禁用状态运行下去，等于是用整台电脑失去防护来换取本该只需补上一条规则就能解决的问题。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。