前几天有人在一个技术交流群里提到，他们一套业务系统突然连不上中心服务器了。我远程一看，软件报错信息指向目标端口18789，排查到最后，问题出在Windows 11防火墙的出站规则上——系统安全策略把默认出站行为改成了阻止，18789端口根本没被放行。加了一条允许TCP 18789端口出站的规则之后，系统恢复如初。
这个案例特别典型。很多人对Windows防火墙入站规则比较熟，出站规则却容易忽略。本文就围绕这个18789端口，把配置原理、图形界面操作、命令行方式、验证手段和排障经验一次说清楚，无论你是刚接触Windows系统管理，还是已经维护过一批机器，都能直接照着操作。
1. 先搞清楚端口18789与出站规则的真实用途
1.1 什么场景下需要给18789端口放行出站
实际工作中，端口号不是随便填的。18789这类非知名端口，通常来自业务软件的固定配置。常见场景有几种。
第一类是数据上报类。本机运行着数据采集客户端，需要周期性地把采集结果通过TCP连接回传到中心服务器，中心服务端监听的就是18789端口。此时本机是主动发起连接的一方，所以防火墙要放行“出站”方向。
第二类是应用对接类。本机上的某个中间件需要直连远端数据库或者API网关，对方只开放了18789这个业务端口，为了安全和简化运维，连接配置里把端口写死成18789。本机每次访问都是主动向对方建连。
第三类是设备联调。工业现场或实验室里的一台工控机、嵌入式网关，需要向中心服务器上报状态或接收指令，传输协议固定为TCP 18789。网络策略一收紧，本地Windows防火墙就会把这类出站连接拦住。
不管是哪类，本质都一样：本机是客户端，目标端口是18789，数据要往外走。配置的方向写错，或者端口位置填错，规则就形同虚设。
1.2 出站规则和入站规则，到底谁管谁
用打电话来类比最合适。出站就是“你想打电话给别人”，你的请求先拨出去，对方接听之后谈话内容才会流动；入站则是“别人打电话给你”，你的电脑相当于被叫方。Windows防火墙对“主动打出去”的这一侧用出站规则控制，对“被叫进来”的一侧用入站规则控制。
从TCP协议角度更精确。一次连接建立时，本机发出第一个SYN报文，这个报文属于出站流量；目标主机回SYN+ACK，那是回应流量。Windows防火墙有状态检测机制，会自动放行已建立连接的回应包，所以真正需要过滤的是本机主动发起连接的那一刻。给18789端口放行出站，本质就是允许本机向外发起目标端口为18789的连接，让数据包通过防火墙检查。
有些朋友会困惑：“我设置了出站放行之后，对方发给我的数据算入站吗？要不要再开一条入站规则？”答案是不需要。一旦出站连接建立成功，连接状态会被防火墙跟踪，后续这个连接上的双向数据包都属于已建立连接的一部分，不会再被入站规则拦截。这一点在排障时尤其重要，能避免你去做无效配置。
1.3 Windows 11防火墙上出站到底默认开没开
很多新手会问：“既然Windows防火墙默认允许出站，那我为什么还要手动加规则？”
严格来说，Windows 11家庭版和专业版在默认安装状态下，出站策略是“允许”（Allow），也就是所有出站连接默认放行，不弹窗、不记录。所以在一台全新电脑上，大概率不需要配18789出站规则也能连上。
但这里有个大前提：只要系统被域策略管理，或者装了第三方安全软件，甚至你自己做过安全加固，出站默认策略就会从“允许”改成“阻止”。我遇到的那位群友，就是公司终端在域环境里被统一收紧了出站策略，默认出站全部拦截，仅对白名单端口放行。这种情况下，18789不在白名单，连接必然失败。
另外，即便默认放行，从审计和精细化管控的角度，也需要主动建一条显式规则。一来故障时可以快速判断“端口到底放没放过”，二来安全扫描时可以统一盘点业务端口。把规则命名写得规范一点，后期排障能省很多时间。
2. 图形界面里添加允许18789端口出站的详细步骤
2.1 打开防火墙高级安全管理器
图形界面操作最直观，适合单个服务器、单台电脑手动配置。
在Windows 11上，按“Win+R”打开运行窗口，输入wf.msc回车。如果弹出用户账户控制（UAC）提示，点“是”继续。这里打开的是微软管理控制台里的防火墙高级安全界面，比“设置”里的普通防火墙面板功能全得多，可以配置出站规则、入站规则、连接安全规则。
打开后左侧会看到三个主要节点：“入站规则”“出站规则”“连接安全规则”。我们要操作的是中间这个“出站规则”。右边栏有“新建规则”和“筛选”等快捷入口。
提示：如果你平时用“设置 > 隐私和安全性 > Windows安全中心 > 防火墙和网络保护”，那个界面只能看到防火墙状态和基础开关，无法新建规则。新建出站规则必须使用wf.msc这类高级管理工具。
2.2 新建端口出站规则的具体配置
在“出站规则”节点上右键，选择“新建规则”，会弹出新建出站规则向导。按下面的配置一步步走：
- 规则类型选择“端口”，下一步。
- 协议选择“TCP”。大多数业务系统使用TCP，标题里的18789如果没有特别说明是UDP，优先按TCP处理；如果业务协议明确写了UDP，就选UDP。
- 这一步最关键：在“特定远程端口”里填18789，而不是“特定本地端口”。很多人在这一步把方向搞反。出站连接的目标服务器端口，对于本机来说就是“远程端口”。如果你选成本地端口，规则会去匹配本机源端口为18789的流量，而正常客户端发起连接时源端口是随机高位端口，规则根本匹配不到。
- 操作选择“允许连接”。
- 配置文件三个都勾上：域、专用、公用。如果你想严格一点，可以只勾当前网络类型，但更稳妥的做法是全选，避免以后换了网络环境规则失效。
- 名称填“Allow TCP 18789 Outbound”，或者按你们公司规则命名，比如“业务上报-允许出站TCP18789”。描述里可以写清楚用途，比如“放行中心服务器上报流量”。
点击“完成”后回到出站规则列表，能看到这条规则已启用。此时规则的适用范围是所有程序、所有远程IP地址，只要目标端口是18789的TCP出站连接都会被放行。
2.3 端口规则和程序规则的取舍
端口规则优点是简单直接，缺点是不能区分是哪个程序在用这个端口。如果系统里有恶意程序也走18789往外连，端口规则会一起放行。在安全要求高的环境里，更建议使用“程序”规则。
新建规则向导第一步选“程序”，第二步指定程序路径，比如“C:\Program Files\某跨平台系统\client.exe”，第三步默认或自定义协议和端口。如果你还能把这个程序允许访问的远程端口收窄到18789，那就更好了。操作上在向导的“协议和端口”页面勾选“TCP”，然后在“特定远程端口”里填18789。
这样做的效果是：只有该程序发起的、目标端口为18789的连接才被放行，其他程序就算占了18789也出不去。缺点是需要知道程序的固定路径，而且程序升级换了安装目录，规则会失效，需要同步修改路径。
还有一个容易踩坑的地方：很多Windows服务是由svchost.exe承载的，如果你创建程序规则指向一个不明确的宿主进程，会导致规则永远匹配不上。对于这类服务型业务的端口放行，直接用端口规则反而更可靠。
3. 使用命令行与PowerShell快速批量放行18789
3.1 netsh添加出站规则，注意别把端口填错方向
服务器批量初始化或者临时排障时，用命令行比鼠标点向导快得多。netsh是Windows自带的网络配置工具，兼容性很好，在普通命令提示符或者PowerShell里都能执行，但需要管理员权限。
添加允许18789出站规则，命令如下：
netsh advfirewall firewall add rule name="Allow TCP 18789 Outbound" dir=out action=allow protocol=TCP remoteport=18789拆解一下参数：
- name：规则名称，建议有辨识度，因为后面修改和删除都靠它。
- dir=out：出站方向，out就是Outbound。注意别写成in。
- action=allow：允许连接。
- protocol=TCP：传输协议。如果是UDP改成protocol=UDP。
- remoteport=18789：远程端口。这里对应的就是图形界面里的“特定远程端口”。再次强调，不要写成localport。如果你在图形界面或者文档里看到有人让你用localport=18789，要立刻警觉，除非你确实是想匹配本机源端口。
如果业务访问的是固定服务器，想把作用域缩小，可以加上remoteaddr参数指定目标IP：
netsh advfirewall firewall add rule name="Allow TCP 18789 Outbound to 192.0.2.10" dir=out action=allow protocol=TCP remoteport=18789 remoteaddr=192.0.2.103.2 使用PowerShell的New-NetFirewallRule来管理
Windows 11里更推荐用PowerShell的防火墙模块，参数语义清晰，出错率低，还支持写脚本批量管理。
同样的规则用PowerShell创建：
New-NetFirewallRule -DisplayName "Allow TCP 18789 Outbound" -Direction Outbound -Protocol TCP -RemotePort 18789 -Action Allow -Profile Any参数对照如下：
- DisplayName：规则显示名称，对应netsh的name。
- Direction：Outbound表示出站。
- Protocol：TCP或UDP。
- RemotePort：远程端口，这里是18789。
- Action：Allow。
- Profile：Any相当于三个配置文件都选；如果只想应用到公用网络，改成Profile Public。
如果你要用本地端口匹配，需要把-RemotePort换成-LocalPort。本质上和netsh一致，只是参数名更直观。
批量场景下，你可以写一个简单脚本循环处理多台机器或者多个端口。比如在内网批量开放一组端口时，把端口列表放进一个数组，循环执行New-NetFirewallRule即可。
3.3 规则的查看、修改与删除命令备忘
配置完了总要验证一下规则是否存在、是否启用。
用netsh查看出站规则里包含18789的条目：
netsh advfirewall firewall show rule name="Allow TCP 18789 Outbound"用PowerShell查看：
Get-NetFirewallRule -DisplayName "Allow TCP 18789 Outbound" | Select-Object DisplayName, Direction, Action, Enabled, Profile如果你只看到规则，但不确定端口设置得对不对，可以查看端口过滤器：
Get-NetFirewallRule -DisplayName "Allow TCP 18789 Outbound" | Get-NetFirewallPortFilter输出里的RemotePort会显示18789。如果显示的是LocalPort有值、RemotePort为空，说明规则建错了方向。
修改规则端口时，PowerShell可以这样操作：
Set-NetFirewallRule -DisplayName "Allow TCP 18789 Outbound" -RemotePort 18789不过我个人的经验是，改不如删了重建。规则一旦被修改过，显示状态有时候会变得很难排查，直接删除干净再添加反而稳妥。
删除规则：
Remove-NetFirewallRule -DisplayName "Allow TCP 18789 Outbound"对应netsh：
netsh advfirewall firewall delete rule name="Allow TCP 18789 Outbound"4. 放行之后怎么验证18789出站是真的通了
4.1 用PowerShell自带命令做端口连通性测试
规则加完不一定就通了，得验证。验证出站连接最直接的方式是用Test-NetConnection测试到目标主机18789端口的连通性。
Test-NetConnection 192.0.2.10 -Port 18789输出里重点看两个字段：TcpTestSucceeded，如果显示True，说明本机到目标服务器18789端口的TCP连接能建立，出站放行已生效；如果显示False，则要按第5章的顺序继续排查。
注意，这个测试要求目标服务器上的服务端已经在监听18789端口。如果对端服务没起来，端口跟本机防火墙规则没关系，也会显示False。
也可以连续测试多次，看看是否稳定：
1..5 | ForEach-Object { (Test-NetConnection 192.0.2.10 -Port 18789).TcpTestSucceeded }如果返回真假交替，大概率不是防火墙规则问题，而是链路或者对端服务不稳定。
提示：旧文档常提到用telnet测试端口，但Windows 11默认不装telnet客户端。虽然可以通过“启用或关闭Windows功能”打开，但为了少折腾，直接用PowerShell的Test-NetConnection更方便。
4.2 用网络抓包确认防火墙没有暗中拦截
端口测试只能说明“连不上”，不能直接证明是Windows防火墙拦的还是网络链路拦的。这时候抓包很有用。
Windows 11内置了pktmon工具，可以在不装第三方抓包软件的情况下收集网络包。以管理员身份启动PowerShell：
pktmon start --etw -p Microsoft-Windows-Kernel-Network然后复现一次连接失败的过程，停止并格式化日志：
pktmon stop pktmon format pktmon.etl -o out.txt生成的out.txt会记录网络事件。重点看有没有目标地址192.0.2.10、端口18789的SYN包被丢弃。如果SYN包根本没发出去，说明出站被本机防火墙或策略拦截；如果SYN发出去了但没有回应，说明问题在链路或者对端。
当然，如果环境允许装Wireshark，直接抓网卡流量更直观，显示过滤器可以写tcp.port == 18789。
4.3 检查规则状态和配置文件是否匹配
还有一种很隐蔽的情况：规则本身存在，显示启用，但依然不生效，因为规则绑定的配置文件跟当前网络类型对不上。
Windows 11系统托盘点开网络图标，进入“设置 > 网络和Internet > 属性”，能看到当前网络配置文件是“公用网络”还是“专用网络”。如果企业Wi-Fi显示的是公用网络，而你的防火墙规则只勾了“域”和“专用”，这条规则在当前网络上就不起作用。
检查规则的配置文件归属，用PowerShell：
Get-NetFirewallRule -DisplayName "Allow TCP 18789 Outbound" | Select-Object Profile返回结果是Any、Domain、Private、Public之一。如果当前网络是公用，而规则Profile里没有Public，就得改规则。
修改配置文件归属：
Set-NetFirewallRule -DisplayName "Allow TCP 18789 Outbound" -Profile Public或者更省事，创建的时候直接加-Profile Any，以后再也不用担心网络类型切换导致规则失效。
5. 实际排障心得：规则加了之后依然不通怎么办
5.1 先按顺序排查这5个原因
规则加了好几个小时，端口还不通。这种情况我见过太多次了，按下面的排查顺序一步步走，大多能定位。
第一，先检查是否存在高优先级的阻止规则。Windows防火墙的规则优先级是“阻止优先于允许”，不管规则创建顺序如何，只要存在一条同时匹配流量特征的阻止规则，允许规则就不生效。用下面的命令查一下有没有针对18789出站的阻止规则：
Get-NetFirewallRule -Direction Outbound | Get-NetFirewallPortFilter | Where-Object { $_.RemotePort -in 18789 } | ForEach-Object { $rule = $_ | Get-NetFirewallRule; if ($rule.Action -eq 'Block') { $rule.DisplayName } }第二，检查默认出站策略。虽然前面说了家用的Windows默认出站允许，但在域环境或者加固系统里，出站默认是Block。可以查一下：
Get-NetFirewallProfile | Select-Object Name, DefaultOutboundAction如果显示Block，那你的允许规则就是白名单里的一员，一旦规则没匹配上，其余流量全部被拦。
第三，确认规则端口方向。这是所有问题里最高频的坑。回到第2.2节说的，出站到目标服务器的时候，规则里填的是远程端口18789，不是本地端口。如果你建的规则端口过滤器里LocalPort=18789而RemotePort为空，那它根本匹配不到你的业务流量。
第四，确认目标服务器端口没有做白名单限制。很多远端服务会在服务器防火墙或者云安全组层面只允许特定来源IP访问18789。本机允许出站，但出站包到了远端还是被拦，也会导致连接失败。这时候本机测试看到的仍然可能是超时或拒绝。
第五，看看是不是有第三方安全软件在拦截。装了第三方安全套件或者EDR之后，Windows自带的防火墙规则可能不会被严格执行，第三方会做独立的出站管控。检查一下安全软件的“网络防护”模块，把业务程序加入信任区。
5.2 常见问题速查表
我把排障中经常遇到的现象整理成一个速查表，方便直接对照：
| 现象 | 可能原因 | 处理办法 |
|---|---|---|
| 规则已启用但不匹配流量 | 端口填到本地端口了 | 改为远程端口18789 |
| 网络类型切到公用后不通 | 规则只关联了域或专用 | 设置Profile为Any或Public |
| 程序规则升级后失效 | 程序安装路径变了 | 修改规则中的程序路径或改用端口规则 |
| 出站默认策略是阻止 | 域策略或安全加固配置 | 显式添加允许规则并确认顺序 |
| 目标端口在远端仍被拦截 | 服务端防火墙/云安全组限制 | 在服务端加白本机IP |
| 同流量同时存在阻止规则 | 策略冲突 | 删除或禁用阻止规则 |
5.3 几条长期维护防火墙规则的经验
最后说几条我自己的习惯，供参考。
第一，规则命名要有业务可读性。别叫“rule1”或者“test”，建议格式是“业务名-方向-协议-端口-操作人”，比如“采集上报-出站-TCP-18789-A”。创建的时候严格一点，半年后回头看，这些命名能救命。
第二，能细就细。如果业务只访问固定服务器，就把远程地址也写进去，别用任何IP。出站规则范围越小，被恶意利用的风险越低。
第三，定期导出备份。在wf.msc里右键“导出策略”，或者用PowerShell把规则导出为文件，方法很多。系统重做、迁移环境时，规则直接还原能省一个下午。
第四，别用“临时开一天就删”的心态替代正常配置。“临时”规则往往变成“永久”没人敢动的规则，安全审计查出来全是问题。
关于Windows 11防火墙放行18789端口出站这件事，我个人踩过的坑里，印象最深的就是本地端口和远程端口的混淆。第一次帮别人配置时，我在图形界面里把18789填进了“本地端口”，结果折腾了两个小时没效果，最后才意识到出站连接匹配的是对端端口。后来我养成了一个习惯：不管用图形界面还是命令行，添加完规则后一定先查一遍端口过滤器，确认RemotePort写对了再去做连通性测试。希望这篇内容能帮你少走这些弯路。如果业务环境更复杂，比如有多网卡、多个网络配置文件交替切换，也别忘了先把网络类型和配置文件这层对清楚，再回头看规则本身。
