Windows 防火墙与业务应用——入站规则要在安装程序中注册

“在开发机上能跑，装到客户的电脑上之后，别的机器就连不上了。”遇到这类咨询，怀疑 Windows 防火墙是合理的。但是，无法通信和防火墙在拦截，并不是一回事。 有时是应用根本没有监听，有时是连接目标或端口不对，还有时是允许规则与网络的条件不匹配。

开发机上可能还留着过去创建的允许规则。在这种状态下做的验证，并不能重现全新部署环境的行为。不要假定有人会在首次启动的警告里点允许，而要把放行哪些通信、由谁放行、在哪个阶段放行写进产品的部署步骤。Microsoft 同样建议在应用首次启动之前就部署好必要的规则。¹

本文以接受来自其他机器的 TCP 连接的业务应用为主要例子，梳理规则的设计、在安装程序中的实现，以及客户现场无法通信时的检查顺序。内容面向 Windows 11 和 Windows Server 的运维场景，技术说明依据 2026 年 9 月 8 日核实的 Microsoft 公开资料。命令中的产品名、路径、端口和 IP 范围都是示例，请按实际环境替换。

1. 先说结论

需要先掌握的有以下 3 点。

• 是否需要入站规则，取决于通信方向，而不是应用的名字。 要区分应用只是自己发起连接，还是要监听来自其他机器的新连接。²
• 必要的规则要在首次启动之前部署好。 允许本地管理的机器可以用安装程序，由组织集中管理的机器可以选择用 GPO 或 Intune 等方式分发。¹
• 出问题时，按监听、TCP 连接、网络配置文件、规则、日志的顺序检查。 关键是不要仅凭规则存在就断定通信已放行，也不要仅凭没有日志就断定数据包没有到达。³⁴⁵⁶

本文“在安装程序中注册”这个结论，并不是说要覆盖组织的管理策略，而是说把通信所需的配置放在责任明确的部署工序里完成，而不是交给用户的首次操作。

图中实线表示始终成立的关系，虚线表示带条件的关系（成立条件写在详情页各关系的说明中）。关系的完整列表（共 35 条，附依据与确信度）以及主要概念的定义，汇总在知识地图详情页（日文）。数据：JSON-LD / Turtle

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

Windows 防火墙是控制本机自身通信的主机型防火墙。默认情况下，凡是既不属于对请求的响应、也不匹配允许规则的入站通信都会被阻止；出站通信在没有阻止规则之类配置的情况下会被允许。这是 Windows 的默认值，并不保证客户现场的管理员没有改动过。²

例如，订单客户端要连接订单服务器的 TCP 50051 时，接受新连接的是服务器一侧。客户端为了接收该连接上的响应，并不需要开放同一编号的入站端口。²

远程命名管道使用 SMB。常见的直接承载式 SMB 使用 TCP 445，因此只针对自研应用的 exe 放行未必能解决问题。请区分本地使用命名管道和跨网络使用命名管道。SMB 的身份验证和访问权限也需要另行准备。⁷⁸

下图以默认阻止入站为前提，用于找出应用中接受来自其他机器连接的部分。图中的“必须有入站规则”指的是需要有允许入站的配置；如果现有的集中管理规则已经足够，应用就不必再添加重复的规则。仅在同一台电脑内部的通信以及 UDP 通信，要与这张 TCP 连接的图分开处理。

flowchart TB
    APP["梳理自研应用的通信"] --> Q{"是否开放端口<br/>监听连接"}
    Q -- "不监听<br/>(只作为客户端发起连接)" --> C1["入站规则原则上不需要<br/>连接的返回作为“响应”通过"]
    Q -- "监听<br/>(服务器型、接收回调)" --> S1["必须有入站规则<br/>→ 在安装程序中注册(第 5 节)"]
    C1 -.-> EX["例外：在出站默认阻止的<br/>高安全环境中要申请出站规则"]

在出站默认值已被改为阻止的环境，或者存在明确禁止目标应用出站的规则的环境中，发起连接的一侧也需要放行。不能断定“因为是客户端，所以与防火墙无关”。¹ 如果想先梳理通信方式本身，可以参考进程间通信的选择方法。

2.1. 网络配置文件与“网络位置”

规则带有一个条件，即它在哪个网络配置文件下生效。典型的适用思路如下。²

可以用下面的命令确认当前连接的网络。在有多个适配器或 VPN 的机器上，除了名称，还要核对实际用于通信的接口。²

Get-NetConnectionProfile |
    Select-Object InterfaceAlias, InterfaceIndex, NetworkCategory

只限定域和专用的规则，如果目标通信属于公用配置文件，就不会被应用。但重要的是，不要为了让通信通过就把网络改成专用，也不要把规则扩大到所有配置文件。客户现场的网络在多大程度上可信、允许在哪个配置文件下使用，要与管理员一起确定。

2.2. 规则的优先级

在普通的允许与阻止规则中，明确的允许优先于默认的入站阻止，但匹配同一通信的明确阻止规则，优先于与之冲突的允许规则。这不是后添加的规则取胜的机制。¹

因此，遇到“添加了允许规则却没有变化”的情况，除了检查允许的条件是否匹配，还要排查作用于同一应用或同一端口的阻止规则。仅仅存在一条拦截无关通信的规则，并不会让那台机器的所有通信都中断。使用 IPsec 身份验证的特殊绕行规则等，与本文讨论的普通允许规则属于不同的设计。

3. “安全警报”对话框的真相——不能交给它处理的理由

当没有对应规则的应用开始监听时，根据配置和运行情况，会弹出“Windows Defender 防火墙已阻止此应用的部分功能”这样的通知。在关闭了通知的受管理机器上不会显示，因此没有弹出警告，并不能作为通信已被放行的证据。¹

Microsoft 说明的、通知显示之后的行为如下。¹

一旦这个机制创建的规则留了下来，重启应用也无法再次得到同样的确认提示。特别是已经生成了阻止规则时，仅添加允许规则可能解决不了问题。应先确认规则的来源和必要性，再由管理员限定对象进行清理。组织有意分发的阻止规则，不能由应用一侧删除。

下图是通知创建规则的流程。通知实际显示的条件和界面上的措辞，会因操作系统和管理配置而不同。

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 路径改变这些情况。先把需要的通信梳理清楚，在首次启动之前准备好规则，部署过程才更有可重现性。¹

对于由非管理员使用的机器，Microsoft 建议事先部署规则并禁用入站通知。通知可以用 Set-NetFirewallProfile -NotifyOnListen False 或组策略来控制，但这属于管理方对整台机器通知方针的决定。它并不构成业务应用的安装程序擅自修改会影响其他应用的通知配置的理由。关闭通知，并不等于需要的通信就被放行了。¹⁹

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

首先把通信规格拆成“入站／出站”“TCP／UDP”“监听端口”“执行主体”“来源”“使用的网络”几项写下来，然后再组合规则的条件。¹⁰

-Program 指定的不是快捷方式或启动器，而是实际负责通信的 exe。如果是由另外的服务或宿主进程负责监听的架构，就需要针对那个执行主体来设计。即使使用动态端口，也不要马上无条件放开所有端口，而应考虑通过程序、服务、来源等能收窄到什么范围。¹⁰³

此外，用 -Profile 限定使用的网络，用 -RemoteAddress 限定来源。例如，订单客户端的部署范围确定为 172.16.10.0/24 时，就指定这个范围。LocalSubnet 是在小规模网络等场景下可用的写法，但它并不意味着会自动包含“公司所有站点”或“VPN 对面”。请确认实际的通信路径，以及入站一侧看到的来源地址。¹¹⁰

只使用 TCP 的功能，没有必要为了以防万一也把 UDP 放行。另外，如果要让仅限公司内部使用的功能在公用配置文件下也生效，就要能另行说明其必要性和来源限制。规则设计的出发点是只放行来自必要对端、属于必要程序的必要通信。

5. 在安装程序中注册的实务——netsh 与 New-NetFirewallRule

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

注册、修改、删除整台机器的防火墙规则，要以提升后的管理员权限执行。即使用户属于管理员组，也不等于可以不经 UAC 提升。¹¹

把注册处理放在安装程序中已提升权限的工序里，应用本体就不需要一直以管理员身份运行。反过来，只靠标准用户就能完成的按用户安装的安装程序，没有修改整台机器规则的权限。这种情况下，要把管理员单独执行的配置，或者由组织分发规则，作为部署的前提条件。请把需要管理员特权的场景与日常运行应用所需的权限区分开。

下面的例子假定自研 exe 在固定端口上监听，而且这台机器允许由安装程序管理本地规则。其中不包含解除管理策略限制的处理。

5.2. 用 netsh advfirewall 注册

用 netsh 可以像下面这样一次性指定程序、TCP 端口、网络配置文件和来源。这是在尚未创建同一规则的机器上首次注册的示例，设想为从以管理员身份启动的命令提示符，以批处理文件的形式执行。¹¹

@echo off
netsh advfirewall firewall add rule ^
  name="MyCompany OrderServer TCP 50051 In" ^
  dir=in action=allow enable=yes ^
  program="C:\Program Files\MyCompany\OrderServer\OrderServer.exe" ^
  protocol=TCP localport=50051 ^
  profile=domain,private remoteip=172.16.10.0/24
if errorlevel 1 exit /b 1

重复执行同一条 add rule 不会变成更新，而可能让同名规则不断增加。先删除再重新创建的做法也有问题：删除之后如果注册失败，规则就没有了。对于会反复执行修复和更新的产品，建议采用下一小节那样固定标识符、更新已有规则的设计。

卸载时的命令是另一回事。下面的删除处理只在卸载时执行，不要追加到上面注册批处理的末尾。 它以名称匹配的规则为对象，因此要使用不会与其他产品冲突的名称。¹¹

netsh advfirewall firewall delete rule name="MyCompany OrderServer TCP 50051 In"

把退出码和错误输出记录到安装程序的日志里，区分“注册失败”“已经删除过”“没有权限”这几种情况。同样重要的是，注册已经失败时，不要向用户显示通信准备已经完成。

5.3. 用 PowerShell（New-NetFirewallRule）注册

在 PowerShell 的 NetSecurity 模块中，用于标识规则的 -Name 和显示在界面上的 -DisplayName 是分开的。脚本中的标识符要使用不受显示语言和文案改动影响的固定 -Name。¹⁰

下面是用于安装、修复和更新的示例，重复执行同样的处理也不会让规则增加。已有规则时使用 Set-NetFirewallRule，没有时使用 New-NetFirewallRule。更新显示名称时使用的参数是 -NewDisplayName。¹²

# 安装、修复、更新用。以管理员身份执行。
$ErrorActionPreference = "Stop"
$ruleName = "MyCompany-OrderServer-In"
$displayName = "MyCompany OrderServer (TCP 50051 入站)"
$program = "C:\Program Files\MyCompany\OrderServer\OrderServer.exe"

if (-not (Test-Path -LiteralPath $program -PathType Leaf)) {
    throw "找不到可执行文件：$program"
}

# 本产品自己管理的本地规则的配置。
# 来源和网络配置文件要替换为与部署方管理员达成一致的值。
$settings = @{
    PolicyStore   = "PersistentStore"
    Direction     = "Inbound"
    Action        = "Allow"
    Enabled       = "True"
    Program       = $program
    Protocol      = "TCP"
    LocalPort     = 50051
    Profile       = @("Domain", "Private")
    RemoteAddress = "172.16.10.0/24"
}

# 区分“规则不存在”和获取本身失败这两种情况。
$existing = @(Get-NetFirewallRule -PolicyStore PersistentStore -ErrorAction Stop |
    Where-Object { $_.Name -eq $ruleName })

if ($existing.Count -eq 0) {
    New-NetFirewallRule -Name $ruleName -DisplayName $displayName @settings |
        Out-Null
} else {
    Set-NetFirewallRule -Name $ruleName -NewDisplayName $displayName @settings
}

这个示例修改的只是 PersistentStore 中由本公司管理的那个名称的规则。请不要把同一个标识符用于别的用途。另外，如果产品后来追加了来源端口、服务等条件，这些条件的迁移也要明确设计。Set-NetFirewallRule 并不会把未指定的条件全部恢复为初始状态。¹²

删除要单独放到下面这段仅用于卸载的处理中。如果目标规则不存在就什么都不删除，但获取规则或删除本身的失败不会被隐藏。⁵⁹

# 卸载用。不要与注册处理连续执行。
$ErrorActionPreference = "Stop"
Get-NetFirewallRule -PolicyStore PersistentStore -ErrorAction Stop |
    Where-Object { $_.Name -eq "MyCompany-OrderServer-In" } |
    Remove-NetFirewallRule -ErrorAction Stop

这些只是注册处理的示例，并没有实现安装程序整体的事务处理。集成到产品中时，要确认配置变更的失败会传递给安装程序、更新失败时能回退到旧版本和旧配置、卸载时只删除本公司的规则。

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

按程序指定的规则，以注册时的路径作为条件。例如，即使存在针对 v1.0 文件夹中 exe 的规则，更新后改由 v1.1 文件夹中的 exe 监听时，那条旧规则也不会匹配新的 exe。¹¹⁰

下图表示的是只依赖那条旧路径规则的情况。它并不涵盖存在另一条有效允许规则的情况，也不涵盖不会显示通知的运行状况。

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.3 节的做法，可以用同一个 -Name 把规则更新为新路径。如果选择删除旧规则再重新注册，就要把失败时的还原一起实现，避免只留下旧的宽泛放行。

在 MSI 中，也有像 WiX 的防火墙扩展那样以声明方式处理规则的机制。在用自研的自定义操作启动命令之前，请先确认所用工具支持的条件，以及它如何处理更新和卸载。¹³ 各种发布方式的取舍见Windows 应用发布方式的选择，杀毒软件的检出见Microsoft Defender 的误报处理。

6. 故障排查——“无法通信”的定位流程

收到报修后，先把“连接的来源和目标”“使用的名称或 IP 地址”“TCP／UDP 与端口”“失败时刻”“应用的报错”凑齐。下面以使用 TCP 的订单服务器为例。注意不要把在服务器一侧检查的项目和在实际连接来源上测试的项目混在一起。

图中的 TcpTestSucceeded=True 表示到被测目标的 TCP 连接成功。它不保证应用的身份验证、TLS 和数据交换也成功，也不保证作为另一个可执行文件的业务应用的出站通信同样被放行。⁴

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)"]

1. 看监听状态时，不仅看端口，还要看地址和进程。 即使显示 LISTENING，如果只绑定在 127.0.0.1 或 ::1 上，那也不是其他机器能直接连上的监听。要确认是否在目标 LAN 地址上监听，以及是否有别的进程占用了同一端口。把 netstat -ano 的 PID 与任务管理器等对照，权限足够时还可以用 netstat -abno 查出可执行文件。IPv4 和 IPv6 要分开确认。³

2. TCP 连接测试要在实际的连接来源上进行。 下面的示例中要确认 RemoteAddress、SourceAddress、InterfaceAlias 和 TcpTestSucceeded。⁴

# 在客户端一侧执行。名称和端口请替换为实际环境的值。
Test-NetConnection -ComputerName sv01 -Port 50051 -InformationLevel Detailed

即使结果是 False，也不能确定原因就是 Windows 防火墙。名称解析、连接目标、通信路径、VPN、网络设备、其他产品的通信管控等都是候选原因。反过来，如果结果是 True，先确认连接目标是否就是预期的服务器，然后再检查业务应用的连接配置、身份验证和协议。用 IP 地址做测试可以用于比较 TCP 可达性，但使用名称的身份验证和证书校验的行为未必相同。这个命令的 -Port 是 TCP 测试，不能用来判断 UDP 是否成功。⁴

第 3 步的网络配置文件和第 4 步的规则，都要以实际生效的配置来确认。 Get-NetFirewallRule 默认查询的是本地持久存储。要查看包含 GPO 等在内的当前策略，需要指定 -PolicyStore ActiveStore。除了规则是否存在，还要确认配置文件一侧的设置。⁵¹⁴

# 在服务器一侧以管理员身份执行。
Get-NetConnectionProfile |
    Select-Object InterfaceAlias, InterfaceIndex, NetworkCategory

Get-NetFirewallProfile -PolicyStore ActiveStore |
    Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction,
        AllowInboundRules, AllowLocalFirewallRules

$rules = @(Get-NetFirewallRule -PolicyStore ActiveStore -TracePolicyStore |
    Where-Object { $_.Enabled -eq "True" -and $_.Direction -eq "Inbound" })

$rules | Select-Object Name, DisplayName, Action, Profile,
    PolicyStoreSourceType, PolicyStoreSource

在 AllowInboundRules 被禁用的配置下，仅添加允许规则并不能放行入站通信。另外，本地规则是否会被应用，要结合第 7 节的管理策略一起判断。对于 NotConfigured 这类未配置值，不要只凭这个字符串就断定放行与否，应向管理员确认实际生效的配置。¹⁵

程序、端口和地址位于与规则关联的筛选器对象中。下面的示例分别显示本公司规则的各项条件。$rules 沿用上面命令取得的结果。^5161718

$targetRules = @($rules | Where-Object { $_.Name -eq "MyCompany-OrderServer-In" })
$targetRules | Get-NetFirewallApplicationFilter | Select-Object Program
$targetRules | Get-NetFirewallPortFilter | Select-Object Protocol, LocalPort, RemotePort
$targetRules | Get-NetFirewallAddressFilter | Select-Object LocalAddress, RemoteAddress

# 名称与本公司规则不同的阻止规则也要纳入调查范围。
$rules | Where-Object { $_.Action -eq "Block" } |
    Select-Object Name, DisplayName, Profile, PolicyStoreSourceType, PolicyStoreSource

对阻止规则也一样，要从候选规则出发确认同样的筛选器。如果规则带有服务指定，还要用 Get-NetFirewallServiceFilter 等检查该条件。只做 LocalPort -eq 50051 这样的完全匹配检索，会漏掉指定了 Any 或端口范围的规则。 不要因为“检索没有结果”就认定不存在冲突规则。¹⁷⁵

5. 日志要在启用记录之后再复现问题。 防火墙日志默认既不记录放行也不记录丢弃。默认保存位置是 %windir%\system32\logfiles\firewall\pfirewall.log，最大大小的默认值是 4,096KB。首先确认目标配置文件的设置和实际的保存位置。⁶

# 服务器一侧。先只读取，不修改配置。
Get-NetFirewallProfile -PolicyStore ActiveStore |
    Select-Object Name, LogBlocked, LogAllowed, LogFileName, LogMaxSizeKilobytes

如果丢弃的记录处于禁用状态，就在取得管理员批准后，用 Set-NetFirewallProfile -Profile Private -LogBlocked True 之类的命令只为目标配置文件启用。这里的 Private 只是示例。请记录变更前的设置，调查结束后恢复原值。如果是由组织集中管理的配置，就由管理方来改；没有必要一开始就大量记录放行的通信，或者修改所有配置文件。⁹⁶

如果存在与复现时刻、源 IP、目标 IP、协议和端口都匹配的 DROP，就可以确认该通信被丢弃了。但是，仅凭没有对应的行，不能断定“数据包没有到达”。 要先确认日志配置是否已生效、是不是在看另一个保存位置、文件是否在更新、写入权限有没有问题。必要时再配合抓包等手段。日志文件没有生成时，对文件夹和 mpssvc 权限的确认，也按 Microsoft 的步骤进行。⁶

需要进一步调查时，Windows Filtering Platform 的审核事件 5152 和 5157 也是候选。按数据包审核会产生大量事件，因此 Microsoft 建议用按连接记录的 5157 来监视被阻止的连接。请与管理员确认审核方针和记录量，把范围和期间收窄到必要程度。¹⁹

不要把禁用防火墙当作第一个检查手段或长期对策。 尤其是停止 MpsSvc 服务，Microsoft 不予支持。即使管理员要在隔离的验证环境中做对比测试，也要让服务保持运行、只限定目标配置文件，并把恢复原有配置作为必做步骤。生产环境需要的不是全面撤掉防护，而是针对原因修正配置。²

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

在用 GPO 或 Intune 集中管理防火墙的环境中，可以按配置文件分别禁用“本地规则合并”。这时，即使安装程序能在本地持久存储中创建规则，它也不会作为放行通信的配置生效。注册处理成功，与它在生效策略中起作用，是两件事。¹

图中的“在本地创建的规则”，指的是第 5 节那样写入 PersistentStore 的普通本地规则。它与通过本地组策略配置的规则处理方式不同。这并不是说为了绕开限制就改写到另一个存储，而是为了与客户现场的管理员统一分发来源而做的区分。¹

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

在这种环境中，不要反复重建本地规则，而应请信息系统部门分发规则。安装程序要区分规则是由自己管理，还是以管理方分发为前提，并且在设计上不擅自改动管理方针。

申请时至少要备齐下面这些信息。只写 请开放 TCP 50051，无法确定要为哪台机器、放行谁的通信、放行到什么范围。

部署测试不要只做开发机或服务器自身发起的连接，而要在实际使用的位置和权限下进行。如果存在经由 VPN 等多条路径，就按每条路径分别确认。TCP 连接通了之后在身份验证阶段失败时，就转入与防火墙无关的另一条调查线。相关的身份验证与通信保护话题，可以参考SMB 签名与 LDAP 通道绑定。

8. 总结

处理 Windows 防火墙的问题，不是“在警告里点允许”“开放一个端口”就能收尾的。梳理应用的通信方向，把程序、端口、来源、网络配置文件放在一起设计，并在首次启动之前部署好必要的配置，这才是出发点。¹¹⁰

如果允许本地管理，就把规则的注册、更新和删除纳入安装程序的责任范围。如果由 GPO 或 Intune 管理，就把同一份通信规格交给管理员，由他们分发。请把部署完成的判定条件定为能与预期的对端用真实应用正常通信，并且没有放行多余的范围，而不是能创建出规则。

无法通信时，依次确认监听地址与执行主体、TCP 连接、网络配置文件、生效策略、丢弃日志。不要跳到“连不上就是防火墙”“没有日志就是没到达”这样的结论；把每一项结果已经查明的内容和仍然不清楚的内容分开，下一步该查哪里就清楚了。

相关文章

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

相关咨询领域

合同会社小村软件除了承接 Windows 业务应用开发，还提供包含防火墙规则的安装程序设计、客户现场无法通信问题的原因调查，以及面向组织集中管理环境的部署技术咨询。咨询时如果能提供连接的来源和目标、通信方式、复现步骤以及报错或日志，就能把调查范围具体化。

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

参考链接

相关文章

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

相关主题

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

与本主题相关的服务

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

常见问题

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

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

在出站默认允许的环境中，如果应用只是自己发起连接、并接收该连接上的响应，通常不需要为它单独添加入站规则。但如果存在限制出站的组织策略或明确的阻止规则，情况就不同了。另外，即使名字叫客户端的应用，只要其中有部分功能要等待来自其他机器的回调或通知，就需要配置允许入站。判断依据不是应用的叫法，而是实际的通信方向。

在“Windows 安全警报”对话框中点击“允许访问”不就可以了吗？

更安全的做法是，不让生产环境的部署步骤只依赖这一个操作。按照 Microsoft 的说明，如果看到通知的管理员点了取消，或者操作者不是管理员，系统就会创建阻止规则。事后再添加允许规则，只要存在冲突的阻止规则，通信仍然通不过。必要的规则应在首次启动之前，由安装程序或组织的管理员部署好。

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

如果是在固定端口上监听的自研应用，基本做法是把程序的完整路径、协议和本地端口组合起来，同时把来源 IP 和网络配置文件也收窄到必要范围。动态端口、以服务方式运行等情况，需要按实际架构调整。按程序指定的规则，要在更新处理中同步修改可执行文件的路径变更，不要轻易创建只按端口放行的宽泛规则。

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

规则注册成功，并不等于通信已经被放行。请检查监听地址、可执行文件路径、网络配置文件、来源 IP，以及是否存在冲突的阻止规则。此外，如果 GPO 或 Intune 禁用了本地规则合并，安装程序创建的规则就不会被应用。这种情况下不要绕开管理策略，而应改为由信息系统部门分发规则。

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

请先从监听状态、生效策略和丢弃日志入手排查。不要把整体禁用防火墙当作常规处理手段，尤其要避免停止 MpsSvc 服务，因为 Microsoft 不支持这种做法。即使管理员确实需要在隔离的验证环境中临时禁用，也应让服务保持运行、只限定目标网络配置文件，并记录变更前的设置，用完立即还原。

作者简介

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

Go Komura

小村软件有限公司 代表

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