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 / 自訂 updater 的判斷表
• Windows 什麼時候需要系統管理員特權 - UAC、保護區、設計上的分辨方式
• 自家開發的 Windows 應用程式被當成病毒處理時 ── Microsoft Defender 誤判的因應方式，以及與效能影響的相處之道
• SMB 簽章與 LDAP 通道繫結 ── 在實務中補齊 NTLM 對策的「剩餘一半」
• Windows 服務的建立與維運 ── 從與工作排程器的取捨到把 BackgroundService 做成服務

相關諮詢領域

合同會社小村軟體除了承接 Windows 業務應用程式開發，也提供含防火牆規則在內的安裝程式設計、客戶端無法通訊問題的原因調查，以及面向組織集中管理環境部署的技術諮詢。諮詢時如果能提供連線來源與連線目標、通訊方式、重現步驟，以及錯誤或記錄檔，就能把調查範圍具體化。

• Windows 應用程式開發
• 缺陷調查・原因分析
• 技術諮詢・設計審查
• 聯絡我們

參考連結

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

只是以用戶端身分連線到伺服器的應用程式，也需要防火牆規則嗎？

在輸出預設允許的環境中，如果應用程式只是自己發起連線、並接收該連線上的回應，通常不需要為它另外新增專用的輸入規則。但若組織原則限制了輸出，或存在明確的封鎖規則，情況就不同了。另外，即使名稱叫用戶端的應用程式，只要其中有部分功能要接聽來自其他電腦的回呼或通知，就需要設定成允許輸入。判斷依據不是應用程式的名稱，而是實際的通訊方向。

在「Windows 安全性警訊」對話方塊按下「允許存取」不就好了嗎？

比較安全的做法，是不要讓正式環境的導入步驟只依賴這一個操作。依照 Microsoft 的說明，看到通知的系統管理員按下取消，或是操作者不是系統管理員時，系統就會建立封鎖規則。事後再新增允許規則，只要存在互相衝突的封鎖規則，通訊仍然通不過。必要的規則應該在首次啟動之前，由安裝程式或組織的系統管理員配置好。

輸入規則應該用指定連接埠還是指定程式來建立？

如果是在固定連接埠上接聽的自家應用程式，基本做法是把程式的完整路徑、通訊協定與本機連接埠組合起來，同時把來源 IP 與網路設定檔也收斂到必要範圍。動態連接埠、以服務形式執行等情況，要依實際架構調整。指定程式的規則，必須在更新處理中一併反映執行檔的路徑變動，不要輕易建立只憑連接埠放行的寬鬆規則。

安裝程式登錄的規則，在客戶端的電腦上似乎沒有生效，這是為什麼？

規則登錄成功，並不等於通訊已經被放行。請檢查接聽位址、執行檔路徑、網路設定檔、來源 IP，以及是否存在互相衝突的封鎖規則。此外，如果 GPO 或 Intune 停用了本機規則合併，安裝程式建立的規則就不會被套用。這種情況不要繞過管理原則，而應改為由資訊系統部門發布規則。

為了縮小通訊問題的範圍，可以暫時停用防火牆嗎？

請先從接聽狀態、實際生效的原則與捨棄記錄著手調查。不要把整體停用防火牆當成常規處置，尤其要避免停止 MpsSvc 服務，因為那不在 Microsoft 的支援範圍內。即使系統管理員確實需要在隔離的驗證環境中暫時停用，也要讓服務保持運作、只限定目標網路設定檔，並記下變更前的設定，用完立刻還原。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。