小村軟體有限公司
聯絡我們
選單

Windows 防火牆與業務應用程式 ── 受信規則要在安裝程式中登錄

· · Windows, 防火牆, 網路, 資安, 業務應用程式, 安裝程式, PowerShell, 資訊系統

「開發機上明明沒問題，裝到客戶端卻連不上伺服器」「第一次啟動時跳出了什麼警告，現場人員好像按了取消」「用 netstat 看明明有在待命(listen)這個連接埠，隔壁的電腦卻連不到」── 在業務應用程式的導入現場，這類「無法通訊」的詢問堪稱是最典型的經典案例。而始終高居原因排行榜前段班的，就是Windows 防火牆(Windows Defender Firewall)。

麻煩的地方在於，這個問題在開發機上根本看不出來。因為在開發機上用 Visual Studio 偵錯執行時自己按過允許，或者本來就是以系統管理員身分在操作，所以往往在沒注意到預設會封鎖受信的情況下就把應用程式出貨了。而在客戶端，實際操作的是沒有系統管理員權限的一般使用者，網路也是由 GPO 集中管理。與其說是「原本應該能動卻不動」，不如說事實是「開發機只是碰巧能動」。

本文的對象是在自主開發的應用程式中遇到「客戶端無法通訊」的業務應用程式開發者，以及接獲這類詢問的中小企業資訊部門人員。內容會先最低限度掌握 Windows 防火牆的預設行為與設定檔機制，接著整理受信規則的設計、在安裝程式中登錄的實務做法、問題排查步驟，以及在 GPO/Intune 管理下的注意事項，全部依據 2026 年 8 月當下的第一手資料彙整而成。

1. 先講結論

  • Windows 防火牆的預設值是「受信封鎖、送信允許」。只要不是對請求的回應，受信流量在沒有符合規則的情況下就會被捨棄。1
  • 只有待命(listen)連接埠的伺服器型應用程式才需要受信規則。只從自己這端主動連線的用戶端應用程式，在預設狀態下就能通訊。請先從這一點切入判斷。1
  • 設定檔(profile)共有 3 種(網域/私人/公用)。網域會在偵測到網域控制站時自動套用，公用則是未識別網路的預設值。規則的啟用與否是以設定檔為單位決定的。1
  • 不能把正式環境交給那個「重要警訊」對話方塊處理。系統管理員按下取消就會建立封鎖規則，而沒有系統管理員權限的使用者不論按哪個按鈕都會建立封鎖規則。在刪除已建立的規則之前，對話方塊不會再次出現。2
  • 結論就是「業務應用程式的受信規則要在安裝程式中登錄」。Microsoft 官方本身也建議在應用程式初次啟動前先配置好規則，並停用受信通知。2
  • 規則要以最小權限的方式設計。以「程式+通訊協定+連接埠」為主軸，將設定檔限定在網域/私人，並將遠端 IP 限縮在必要的子網路。程式路徑無法使用萬用字元。23
  • 問題排查的順序是 Test-NetConnection → Get-NetFirewallRule → pfirewall.log。防火牆記錄檔預設不會寫入，必須先啟用捨棄封包的記錄功能才會出現內容。456
  • 透過停止服務來整體停用防火牆，屬於 Microsoft 不支援的操作。在 GPO/Intune 管理下，「本機規則合併」有可能被停用，此時本機規則不會生效，必須向資訊部門申請集中發佈規則。12

2. 正確理解預設行為 ── 受信預設封鎖，送信預設允許

首先要正確掌握基本前提。Windows 防火牆是在所有版本中預設皆為啟用狀態的主機型防火牆，其預設行為可以濃縮成以下兩行。1

  • 受信(inbound)：除非是對請求的回應(solicited)，或符合規則，否則一律封鎖
  • 送信(outbound)：除非符合規則，否則一律允許

從這兩行可以推導出對業務應用程式而言最重要的判斷準則：只有「待命的一方」才需要受信規則。

  • 只從自己這端連線到公司內部 Web 伺服器、資料庫伺服器、核心系統的用戶端應用程式 → 原則上不需要規則。因為連線的回傳封包屬於「對請求的回應」，在預設狀態下就能通過。
  • 使用 TCP、gRPC 或自訂通訊協定等方式，開啟連接埠等待連線的伺服器型應用程式、Windows 服務 → 必須設定受信規則。
  • 另外，從遠端使用具名管道(named pipe)的架構是例外。遠端的具名管道並非透過應用程式自身的連接埠，而是經由 SMB(TCP 445)，因此需要的不是應用程式的規則，而是檔案共用(SMB)那一側的規則。
  • 例外情況是刻意將送信預設值改為封鎖的高安全性環境。這種架構只存在於部分組織中，但若是這種情況，即使是用戶端應用程式也需要申請送信規則。2
不待命(只以用戶端身分連線)會待命(伺服器型、接收回呼)盤點自家應用程式的通訊行為是否會開啟連接埠等待連線原則上不需要受信規則連線的回傳會視為「回應」通過必須設定受信規則→ 於安裝程式中登錄,見第5章例外 - 在送信預設封鎖的高安全性環境中需申請送信規則

「原本以為只是用戶端的應用程式，其實也在待命接收」的情況(例如接收結果的回呼、作為其他行程通知的接收端等)很容易被忽略。如果不確定自家應用程式究竟是用哪種通訊方式在待命，建議在設計階段一併確認「行程間通訊的選擇方式」加以釐清。

2.1 設定檔與「網路位置」

規則是以網路設定檔(profile)為單位套用的。設定檔共有 3 種。1

設定檔 套用條件 常見場景
網域(Domain) 加入 AD 網域的電腦偵測到網域控制站時自動套用。無法手動設定 公司內部網域網路
私人(Private) 由系統管理員手動設定於網路介面上 家庭、小型辦公室的區域網路
公用(Public) 未識別網路的預設值。以最嚴格的前提設計 公共 Wi-Fi、飯店、機場

目前套用的是哪一種設定檔，可以用 Get-NetConnectionProfile 確認；私人／公用之間的切換則可用 Set-NetConnectionProfile 進行。1 現場常見的事故是：客戶端的 workgroup 環境中，網路被判定為「公用」，導致原本限定在網域／私人才生效的受信規則沒有被套用。當出現「明明有規則卻打不通」的情況時，請先懷疑設定檔是否一致，而不是先檢查規則的內容。

2.2 規則的優先順序

當有多條規則存在時，評估方式並不是依照加權排序清單，而是依循以下一貫的原則決定。2

  1. 明確的允許規則優先於預設的封鎖
  2. 明確的封鎖規則優先於相互衝突的允許規則
  3. 在不違反上述第 2 點的範圍內，較具體的規則優先

這在實務上意味著：「只要某處存在一條封鎖規則，之後不管加多少條允許規則都無法勝過它」。正如下一章所見，那個對話方塊正是在悄悄地製造出這種封鎖規則。

3. 「重要警訊」對話方塊的真面目 ── 為什麼不能仰賴它

當應用程式第一次開始待命(listen)某個連接埠時，如果既沒有針對該應用程式的允許規則，也沒有系統管理員自訂的規則，Windows 就會顯示大家熟悉的「Windows 安全性重要警訊」對話方塊，內容是「這個應用程式的部分功能已被 Windows Defender 防火牆封鎖」。其行為規格相當明確。2

  • 顯示給具有系統管理員權限的使用者時：按下「允許存取」會建立允許規則。但是按下「取消」則會建立封鎖規則。通常會建立 TCP 與 UDP 各一條、共 2 條規則。
  • 顯示給沒有系統管理員權限的使用者時：不論選擇哪個選項都會建立封鎖規則。
  • 無論哪一種情況，只要不刪除已建立的規則，對話方塊就不會再次出現，通訊也會持續被封鎖。
有沒有停用啟用系統管理員按下「允許存取」系統管理員按下「取消」沒有系統管理員權限的使用者不論做什麼操作應用程式開始待命連接埠是否有符合該應用程式的規則依規則行事不會出現對話方塊受信通知是否啟用靜默封鎖不會建立規則「重要警訊」對話方塊建立允許規則建立封鎖規則建立封鎖規則在刪除規則之前對話方塊不會再次出現

換句話說，這個對話方塊表面上看起來是「向使用者徵求允許的機制」，但在業務應用程式的現場，實際運作起來卻是「一般使用者一碰就會把封鎖規則烙印下去的機制」。如果導入負責人以系統管理員帳號進行第一次啟動，並在對話方塊中按下允許，那麼建立的允許規則會對整台電腦生效，隔天起一般使用者暫時也能通訊。即便如此，事故仍然可能發生 ── 例如一般使用者第一次觸發了導入時測試沒有測到的待命路徑時、實際套用的網路設定檔與導入時不同時，以及更新後 exe 路徑改變時(第 4、5 章)。

Microsoft 官方本身也針對非系統管理員使用的裝置，明確提出以下最佳實務做法。2

  1. 在應用程式第一次啟動之前，先配置好必要的規則(透過安裝程式或管理端進行部署)
  2. 停用受信通知(關閉通知後，執行時自動建立規則這件事本身就不會發生)

停用通知可以透過 Set-NetFirewallProfile -NotifyOnListen False，或是用群組原則設定。7 「對話方塊出現的話就請現場人員按允許」並不是一套可靠的運用程序，而是預約好的事故。受信規則要在安裝時登錄 ── 這就是本文的結論，也與 Microsoft 的建議一致。

4. 受信規則的設計 ── 指定程式、指定連接埠、指定服務

接下來要設計要登錄的規則內容。指定方式大致分為 3 種系統，需要判斷要單獨使用還是組合使用。

指定方式 適合的情況 弱點・注意事項
指定程式(program= / -Program) 待命連接埠是動態的或有多個。桌面應用程式本體直接待命的架構 只能指定 exe 的完整路徑，無法使用萬用字元2。更新後路徑改變,規則就會找不到對象(5.4 節)
指定連接埠(localport= / -LocalPort) 連接埠是固定的。容易和向資訊部門的申請、網路設備端的設定對齊 同一個連接埠上待命的其他行程也會被放行。需要管理連接埠編號的清單
指定服務(-Service) 以 Windows 服務形式運作的待命行程 以服務名稱(短名稱)限縮對象3。無法用於直接執行 exe 的形態
組合(程式+通訊協定+連接埠) 正式環境業務應用程式的基本形態 條件越多,對環境變化(路徑、連接埠變更)就越脆弱,因此建議把規則內容文件化2

在此基礎上，還要進一步限縮範圍。Microsoft 的設計建議也是「受信規則要盡可能具體」。2

  • 限定設定檔：只在公司內部使用的業務應用程式，其受信規則要限定在網域／私人，不在公用設定檔中啟用。這樣可以防止筆記型電腦一連上公司外的 Wi-Fi，待命的連接埠就對全世界開放這類事故。
  • 限定遠端 IP：如果連線來源已經確定，就把 -RemoteAddress 限縮到該子網路。針對家庭、小型網路，官方建議使用 LocalSubnet 這個關鍵字進行限定。23
  • 方向與條數：如果待命只用 TCP，那麼只要一條 TCP 規則就足夠了。不要因循苟且地像對話方塊自動建立的那樣，同時建立 TCP 與 UDP 兩條規則。

「只從必要的對象，連到必要的連接埠，只允許必要的程式」── 受信規則的設計，就濃縮在這句最小權限的話裡。

5. 在安裝程式中登錄的實務做法 ── netsh 與 New-NetFirewallRule

5.1 前提：需要系統管理員權限

新增、刪除防火牆規則屬於變更整台電腦的設定，因此必須以系統管理員權限(提升後的行程)執行。8 安裝程式通常本來就是以系統管理員權限運作，所以把規則登錄放進安裝流程中是合理的做法。但這不能成為讓應用程式本體以系統管理員身分執行的理由。這種界線的思考方式，在「Windows 什麼時候需要系統管理員權限 - UAC、保護區、設計上的分辨方式」中有詳細討論。

5.2 用 netsh advfirewall 登錄

雖然是比較傳統的做法，但 netsh advfirewall firewall add rule 的優點是不論哪種安裝程式都容易呼叫。8

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 這樣限縮連線來源。8 由於刪除時是以名稱一併清除符合的規則，建議規則名稱加上自家公司的前綴以確保唯一，會比較安全。

5.3 用 PowerShell (New-NetFirewallRule) 登錄

想要更細緻地控制的話，可以使用 NetSecurity 模組。-DisplayName 是必填項目，-Profile 可以用逗號分隔(不含空格)指定多個值。3

# 登錄(從安裝程式以提升權限的狀態執行)。-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 作為從指令碼中識別規則的鍵值。3 為了讓解除安裝程式能確實只刪除自己的規則，請將固定 -Name 視為必要做法。

5.4 更新後 exe 路徑改變的情況

以程式指定的規則會用完整路徑固定對象。也就是說，一旦更新後安裝位置或 exe 名稱改變，規則雖然還在，卻會找不到對象，待命再次被封鎖。此時，新路徑上的 exe 會被視為「沒有規則的應用程式」，在啟用通知的環境中，第 3 章的對話方塊會再次出現，一般使用者一操作就會把封鎖規則烙印下去。而在依照第 3 章建議停用了通知的環境中，甚至連對話方塊都不會出現，就這樣悄悄失敗。採用含版本編號的資料夾配置方式，或是透過自我更新讓部署位置變動的方式，特別容易發生這種事故。

啟用停用對策導入 v1.0規則指向 v1.0 資料夾中的 exe更新後部署到 v1.1 資料夾實際執行的 exe 路徑改變舊路徑的規則找不到對象規則還在但不生效受信通知是否啟用對話方塊再次出現一般使用者一碰就變成封鎖規則連對話方塊都不出現悄悄地被封鎖讓路徑跨版本更新保持固定或在更新處理中刪除舊規則後重新登錄

對策很簡單，就是以下兩者之一。

  • 固定安裝位置，讓 exe 的完整路徑不會因更新而改變
  • 若更新會改變路徑，就讓更新程式刪除舊規則並以新路徑重新登錄(在更新處理中也執行 5.2／5.3 的指令)

如果是 MSI，標準做法是把規則登錄包裝成在檔案部署完成後執行的自訂動作(Custom Action)(解除安裝時則是負責刪除的自訂動作)。WiX 之類的工具組中，也有能以宣告方式描述防火牆規則的擴充功能。實作的位置會因選擇哪種發佈方式而不同，請一併參考「Windows 應用發布方式怎麼選 - MSI / MSIX / ClickOnce / xcopy / 自訂 updater 的判斷表」。另外，在客戶端部署時另一個經典麻煩──防毒軟體的誤判──則在「自家開發的 Windows 應用程式被當成病毒時 ── 與 Microsoft Defender 誤判的應對，以及和效能影響的相處之道」中討論。

6. 疑難排解 ── 「無法通訊」的問題排查流程

先把接獲詢問時要依序執行的步驟固定下來。整體流程如下。

沒有待命處於 LISTENINGTcpTestSucceeded=TrueFalse與規則的對象不一致一致「用戶端無法通訊」伺服器端 - netstat -ano防火牆以前的問題調查應用程式、服務端用戶端 - Test-NetConnection可達性正常調查應用層 - 驗證、通訊協定伺服器端 - Get-NetConnectionProfile確認目前套用的設定檔重新檢視規則的設定檔指定Get-NetFirewallRule -PolicyStore ActiveStore確認是否有允許規則、是否混入封鎖規則用 pfirewall.log 實際確認捨棄 DROP
步驟 指令/操作 要確認的內容
1. 確認是否待命(伺服器端) netstat -ano 目標連接埠是否為 LISTENING。如果根本沒有待命,那就是防火牆以前的問題
2. 確認可達性(用戶端) Test-NetConnection -ComputerName sv01 -Port 50051 TcpTestSucceeded 是否為 True4
3. 確認設定檔(伺服器端) Get-NetConnectionProfile 目前套用的設定檔,是否與啟用規則時所指定的設定檔一致1
4. 確認生效中的規則(伺服器端) Get-NetFirewallRule -PolicyStore ActiveStore 在包含來自 GPO 在內、「實際生效」的規則中,是否有目標允許規則。有沒有混入來自對話方塊的封鎖規則5
5. 用記錄檔確認(伺服器端) pfirewall.log 寄往目標連接埠的封包是否被捨棄(DROP)6

補充說明步驟 4。由於連接埠、程式的條件並不在規則本體上，而是在篩選條件(filter)物件那一側，所以要從連接埠反查規則，必須透過篩選條件來查詢。57

# 反查與連接埠 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,096 KB，必須先啟用「將捨棄的封包記錄到記錄檔」或「將成功的連線記錄到記錄檔」其中一項，才會開始寫入。6 如果是單機，可以用以下方式啟用。6

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

記錄檔是純文字檔，會逐行記錄是捨棄(DROP)還是允許(ALLOW)、通訊協定，以及來源／目的地的 IP 與連接埠，因此可以在這裡確定「究竟是用戶端送出的 SYN 有送達卻被捨棄，還是根本沒有送達」。另外，在透過原則(policy)組態記錄功能的環境中，有時會因為記錄資料夾缺乏寫入權限(服務 mpssvc 的完全控制)而導致檔案沒有被建立，此時需要手動建立資料夾並賦予 ACL。6

如果想再深入追查，啟用稽核原則「篩選平台封包捨棄(Filtering Platform Packet Drop)」後，每次捨棄封包都會記錄安全性事件 5152。不過由於事件數量非常龐大，Microsoft 建議改用以連線為單位記錄的事件 5157(篩選平台連線)。這並不是應該常駐啟用的工具，而是只在排查問題期間才啟用的手段。9

最後，明確指出一種不該採用的排查方式。透過停止防火牆服務(MpsSvc)來整體停用防火牆，屬於不支援的操作，會引發如開始功能表無法運作、市集應用程式更新失敗等作業系統層級的問題。如果無論如何都想停用來確認，正確做法是保持服務運作，改用 Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False 停用設定檔，確認完畢後立刻恢復。17 而且一旦確定原因出在防火牆，該做的處置也不是把停用狀態常態化，而是補上一條正確的規則。

7. 在組織管理下的注意事項 ── 本機規則不生效的環境與申請方式

即使透過安裝程式登錄了規則，也有環境會讓它不生效。在以 GPO 或 Intune(CSP)集中管理防火牆的組織中，可以針對每個設定檔停用「本機規則合併」(AllowLocalPolicyMerge)。這項設定一旦停用，本機系統管理員(包括安裝程式)所建立的規則就不會被套用，需要受信連線的應用程式，其規則就必須透過 GPO/CSP 集中發佈。2

有效(預設)無效GPO/Intune 發佈的規則實際生效的規則集合ActiveStore本機建立的規則包含安裝程式登錄的規則本機規則合併AllowLocalPolicyMerge規則存在但不套用→ 改為透過 GPO/CSP 集中發佈

作為開發方、導入方，現實中的因應對策如下。

  • 把安裝程式的規則登錄設計成「不會失敗」(因為登錄動作本身會成功，無法靠錯誤來偵測，因此要把導入後的連線確認納入標準流程)
  • 用第 6 章步驟 4 的做法(-TracePolicyStore)確認生效中的規則來源究竟是本機還是 GPO5
  • 一旦確認是本機規則不生效的環境，就改為向資訊部門提出規則發佈申請

申請時要把以下資訊整理成一整套交出去。防火牆規則必須方向、程式、連接埠、範圍都齊全才能建立，因此這份清單原封不動就會成為「業務應用程式的網路規格書」。

項目 填寫範例
規則名稱(識別碼) MyCompany-OrderServer-In
方向 受信
程式路徑 C:\Program Files\MyCompany\OrderServer\OrderServer.exe
通訊協定/連接埠 TCP 50051
遠端 IP 範圍 172.16.10.0/24(接單用戶端所在網段)
設定檔 僅網域
用途・依據 接受來自接單輸入用戶端的連線(業務系統名稱)
廢止條件 本系統撤除時刪除

從資訊部門的角度來看，有沒有附上這份表格的申請，作業量完全不同。反過來說，只給連接埠編號、單純要求「請幫我開放」的申請，正如第 4 章所見，很容易變成過度授權。另外，網域環境中檔案共用、驗證相關的通訊需求，也正因為防火牆以外的其他收緊措施(例如強制要求簽章)而有所改變。請一併參考「SMB 簽章與 LDAP 通道繫結 ── 在實務中補齊 NTLM 對策的「剩餘一半」」。

8. 總結

  • Windows 防火牆的預設值是受信封鎖、送信允許。只有待命的伺服器型應用程式才需要受信規則，若只是以用戶端身分連線，原則上不需要。
  • 規則是以設定檔(網域/私人/公用)為單位套用的。「明明有規則卻打不通」時，頭號嫌疑犯就是設定檔不一致。
  • 「重要警訊」對話方塊會因為取消操作，或沒有權限的使用者操作而建立封鎖規則，之後就不會再出現。不能把正式環境的運作交給這個對話方塊。
  • 業務應用程式的受信規則要在安裝程式中登錄 ── 這是唯一的原則。登錄要以系統管理員權限執行，並在實作上連同刪除一起，固定使用 -Name。
  • 規則要以「程式+通訊協定+連接埠」為主軸，再用設定檔與遠端 IP 加以限縮。若更新會改變 exe 路徑，請別忘記重新登錄規則。
  • 排查問題請機械式地依照 netstat → Test-NetConnection → 確認設定檔 → Get-NetFirewallRule(ActiveStore) → pfirewall.log 的順序進行。透過停止服務來停用防火牆屬於不支援的操作。
  • 在 GPO/Intune 管理下，本機規則合併有可能被停用。此時要備齊規則名稱、方向、程式、連接埠、遠端 IP、設定檔等資訊，向資訊部門申請發佈。

相關文章

相關諮詢領域

合同會社小村軟體提供伺服器型業務應用程式的安裝程式設計(包括防火牆規則的登錄與刪除)、客戶端環境「無法通訊」的原因調查，以及以 GPO 管理下部署為前提的網路需求整理等服務。即使只是想從「開發機上能動，但客戶端不能動」開始排查也沒問題。

參考連結

  1. Microsoft Learn, Windows Firewall overview。內容涉及：Windows 防火牆在所有版本中皆為預設啟用的主機型防火牆；預設行為為「受信除了對請求的回應或符合規則的情況外一律封鎖，送信除了符合規則的情況外一律允許」；三種設定檔(網域＝偵測到網域控制站時自動套用且無法手動設定、私人＝由系統管理員手動設定、公用＝未識別網路的預設值)；透過 Get-NetConnectionProfile / Set-NetConnectionProfile 確認與變更網路類別；透過停止防火牆服務(MpsSvc)來停用屬於不支援的操作，會引發開始功能表無法運作、市集應用程式更新失敗等問題；以及正確的停用方式是在服務保持運作的狀態下停用設定檔。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  2. Microsoft Learn, Windows Firewall rules。內容涉及：規則的優先順序(明確的允許優先於預設的封鎖、明確的封鎖優先於允許、較具體的規則優先、不存在加權排序)；應用程式開始待命時若沒有規則就會顯示對話方塊；系統管理員使用者選擇「否」或取消時會建立封鎖規則(通常為 TCP/UDP 各一條共 2 條)；非本機系統管理員的使用者不論選擇哪個選項都會建立封鎖規則；已建立的規則在被刪除之前對話方塊不會再次出現，通訊會持續被封鎖；由應用程式或安裝程式本身新增規則是常見做法；建議在初次啟動前配置規則並停用受信通知；程式規則無法使用萬用字元(如 C:*\teams.exe 等)，只能指定完整路徑；本機規則合併(AllowLocalPolicyMerge)可以按設定檔停用，停用後需要受信連線的應用程式,其規則就必須集中發佈；建議受信規則盡可能具體，並針對家庭、小規模網路建議將遠端位址限定為 LocalSubnet；送信預設封鎖是高安全性環境的選項之一，但不應將受信預設值改為允許。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13

  3. Microsoft Learn, New-NetFirewallRule (NetSecurity)。內容涉及：建立規則時 -DisplayName 為必填；-Name 是唯一識別碼，預設為隨機值，官方指引建議在指令碼中使用 -Name；-Direction (Inbound/Outbound)、-Action (Allow/Block)、-Program (完整路徑)、-Protocol (TCP/UDP/ICMPv4/ICMPv6/編號)、-LocalPort、-RemoteAddress (IP/子網路/範圍/LocalSubnet 等關鍵字)、-Service、-Profile (Any/Domain/Private/Public，可用逗號分隔、不含空格指定多個)等各參數的規格；以及結合指定程式+通訊協定+連接埠建立規則的範例。 ↩ ↩2 ↩3 ↩4 ↩5

  4. Microsoft Learn, Test-NetConnection (NetTCPIP)。內容涉及：Test-NetConnection 是可顯示 ping、TCP 連線、路由診斷資訊的 Cmdlet，透過 -ComputerName 與 -Port 測試對指定連接埠的 TCP 連線，結果會以 TcpTestSucceeded 傳回。 ↩ ↩2

  5. Microsoft Learn, Get-NetFirewallRule (NetSecurity)。內容涉及：使用 -PolicyStore ActiveStore 可以取得目前套用中的所有原則存放區(包含來自 GPO 在內的結果原則集)中的規則；連接埠、位址等條件並不在規則本體，而是位於篩選條件(filter)物件那一側，需透過 Get-NetFirewallPortFilter／Get-NetFirewallApplicationFilter 查詢；以及使用 -TracePolicyStore 可以確認規則的來源(PolicyStoreSource／PolicyStoreSourceType 的 Local/GroupPolicy)。 ↩ ↩2 ↩3 ↩4

  6. Microsoft Learn, Configure Windows Firewall logging。內容涉及：記錄檔的預設路徑為 %windir%\system32\logfiles\firewall\pfirewall.log；預設的最大檔案大小為 4,096 KB，達到上限時會從最舊的項目開始刪除；在啟用「捨棄的封包」或「成功的連線」其中一項之前，記錄檔不會被寫入；使用 netsh advfirewall set allprofiles logging droppedconnections/allowedconnections enable 進行啟用；以及若記錄資料夾缺乏服務 mpssvc 的完全控制權限，有時會導致記錄檔無法建立，此時需要手動建立資料夾並賦予 ACL。 ↩ ↩2 ↩3 ↩4 ↩5

  7. Microsoft Learn, Manage Windows Firewall with the command line。內容涉及：用 Set-NetFirewallProfile 組態預設行為、通知(-NotifyOnListen False)與記錄設定；用 New-NetFirewallRule 建立程式規則的範例，以及用 Remove-NetFirewallRule／netsh advfirewall firewall delete rule 刪除的範例；用 -ErrorAction SilentlyContinue 在規則不存在時抑制錯誤的模式；從 Get-NetFirewallPortFilter 以連接埠條件反查規則的查詢範例；以及用 Set-NetFirewallProfile -Enabled False 停用設定檔，才是正確的停用手段。 ↩ ↩2 ↩3

  8. Microsoft Learn, Use netsh advfirewall firewall context to control Windows Firewall behavior (KB947709)。內容涉及：使用 netsh advfirewall firewall add rule 的語法(name= / dir=in / action=allow / program= / enable=yes / remoteip= / profile= / protocol= / localport=)新增程式規則、連接埠規則的範例；使用 delete rule 刪除的範例；系統管理員群組成員在啟用 UAC 的環境中執行時，必須從提升權限的命令提示字元執行；以及使用 netsh advfirewall set currentprofile logging 進行記錄設定。 ↩ ↩2 ↩3

  9. Microsoft Learn, Audit Filtering Platform Packet Drop。內容涉及：啟用稽核子類別「篩選平台封包捨棄」後，Windows 篩選平台每次捨棄封包時都會記錄事件 5152(以及 5153)；此子類別的事件數量非常龐大，監控被封鎖的連線時，建議使用以連線(而非封包)為單位記錄的事件 5157。 ↩

相關文章

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

相關主題

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

與本主題相關的服務

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

常見問題

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

只是作為用戶端連線到伺服器的應用程式，也需要防火牆規則嗎？
原則上不需要。Windows 防火牆的預設值是「受信封鎖、送信允許」，所以只主動連線出去的用戶端應用程式，在預設狀態下就能通訊。需要受信規則的，只有開啟連接埠等待連線的一方，也就是伺服器型的應用程式。不過有兩個例外。高安全性環境有時會把送信也改為預設封鎖，這種情況就需要申請送信規則。另外，即使是用戶端應用程式，如果設計上是自己開啟連接埠來接收結果通知，那個部分也需要受信規則。
在「Windows 安全性重要警訊」對話方塊按下「允許存取」不就解決了嗎？
當下確實能解決，但不能把正式環境的運作交給它。這個對話方塊，只要具有系統管理員權限的使用者按下取消，就會建立封鎖規則。而且，如果是沒有系統管理員權限的使用者，不論按哪個按鈕都會建立封鎖規則。一旦建立了規則，除非把它刪除，否則對話方塊不會再次出現，通訊也會持續失敗。在現場實際操作 PC 的是一般使用者的業務應用程式中，很容易發生「只要有人按過一次取消，之後就一直無法通訊」的狀況。Microsoft 官方也建議在應用程式第一次啟動之前就先配置好規則。
受信規則應該用指定連接埠還是指定程式來建立？
基本原則是兩者組合使用，而不是單獨用一種。指定程式雖然可以用 exe 的完整路徑限縮對象，但更新後路徑一改變，規則就會找不到對象(無法使用萬用字元)。指定連接埠雖然能讓向資訊部門的申請更明確，但同一個連接埠上待命的其他行程也會一併被放行。正式環境的業務應用程式，最小權限的標準做法是以「程式+通訊協定+連接埠」為主軸，把設定檔限定在網域/私人，再把遠端 IP 限縮到用戶端所在的子網路。只有連接埠是動態的情況，才單獨使用指定程式。
安裝程式登錄的規則，在客戶端的 PC 上似乎沒有生效。這是為什麼？
很有可能是客戶端的防火牆由 GPO 或 Intune 集中管理，並且「本機規則合併」(AllowLocalPolicyMerge)已被停用。這項設定一旦停用，本機建立的規則即使在設定檔上存在，也不會被套用，規則就只能透過 GPO/CSP 端集中發佈。請用 Get-NetFirewallRule -PolicyStore ActiveStore 確認目前生效的規則全貌，並向資訊部門申請規則發佈。申請時只要一併備齊規則名稱、方向、程式路徑、通訊協定與連接埠、遠端 IP 範圍、設定檔等資訊，通常一次就能通過。
為了排查通訊問題，可以暫時停用防火牆嗎？
請絕對避免透過停止服務(MpsSvc)來停用。這是 Microsoft 不支援的操作，會引發開始功能表無法運作、市集應用程式更新失敗等作業系統層級的問題。如果無論如何都想為了排查問題而停用，正確做法是保持服務運作，用 Set-NetFirewallProfile -Enabled False 停用設定檔。不過即使是這種做法，也只限於用幾分鐘的時間確認「原因是否出在防火牆」，一旦確認完畢就要立刻恢復。持續維持停用狀態的運作方式，等於是拿整台 PC 毫無防護的代價，去交換一個原本只要補上一條規則就能解決的問題。

作者檔案

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

Go Komura

小村軟體有限公司 代表

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

聯絡我們
回到部落格一覽