本文可協助您瞭解 Azure 防火牆中目前的已知問題和限制。 我們會在問題解決後更新此資訊，因此請定期回來查看最新狀態。
部署 Azure 防火牆或針對現有部署進行疑難排解之前，請先檢閱這些已知問題，以避免常見問題並規劃適當的因應措施。
如需 Azure 防火牆服務限制，請參閱 Azure 訂用帳戶和服務限制、配額和條件約束。
目前的容量限制
下列區域目前遇到容量限制：
| 地區/區域 | SKU | 限制 | 建議 |
|---|---|---|---|
| 美國東部 2 EUAP 的實體區域 1 和 4 | 基本、標準與進階 | - 你不能在區域 1 和區域 4 部署新的 Azure 防火牆。 | 建議您將新的 Azure 防火牆 部署到其餘可用性區域，或使用不同的區域。 若要設定現有的防火牆，請參閱 如何在部署後設定可用性區域？ |
|
-
實體區域 2 在北歐 - 實體區域 3 在東南亞 |
標準和進階 | - 您無法將新的 Azure 防火牆 部署到東南亞區域 3 或北歐的區域 2。
- 如果您停止在這些區域中部署的現有 Azure 防火牆，就無法重新啟動。 如需詳細資訊，請參閱 實體和邏輯可用性區域。 |
建議您將新的 Azure 防火牆 部署到其餘可用性區域，或使用不同的區域。 若要設定現有的防火牆，請參閱 如何在部署後設定可用性區域？ |
| 物理區域3在美國中南部 | 基本、標準與進階 | - 你無法在第 3 區部署新的 Azure 防火牆。
預計可得日期：2026年3月31日 |
建議您將新的 Azure 防火牆 部署到其餘可用性區域，或使用不同的區域。 若要設定現有的防火牆，請參閱 如何在部署後設定可用性區域？ |
| 在西班牙中央的物理區域2 | 基本、標準與進階 | - 你不能在第 2 區部署新的 Azure 防火牆。
預計可得日期：2026年12月31日 |
建議您將新的 Azure 防火牆 部署到其餘可用性區域，或使用不同的區域。 若要設定現有的防火牆，請參閱 如何在部署後設定可用性區域？ |
| 美國維吉尼亞州政府 | 進階 | - US Gov Virginia 中的 Azure 防火牆進階 SKU 容量為零，區域和非區域部署都會遭到封鎖。 | 部署 Azure 防火牆標準 SKU 或將進階 SKU 部署至不同的區域。 |
| US Gov 維吉尼亞州的實體區域 3 | 基本和標準 | - 在 US Gov 維吉尼亞州的實體區域 3 中，區域性部署遭到封鎖。
- 您必須手動選取可用的區域才能成功部署，以建立次優的部署體驗。 |
選取區域 1 和 2 進行區域部署，或使用不同的區域。 |
| 美國西部 2 中的實體區域 2 | 基本、標準與進階 | - 你不能在第 2 區部署新的 Azure 防火牆。 | 建議您將新的 Azure 防火牆 部署到其餘可用性區域，或使用不同的區域。 若要設定現有的防火牆，請參閱 如何在部署後設定可用性區域？ |
警告
如果您在這些容量限制區域中停止現有的 Azure 防火牆部署，您可能無法因為持續的容量限制而重新啟動它。 在停止這些區域中的防火牆執行個體之前，請進行相應的規劃。
Azure 防火牆標準已知問題
Azure 防火牆標準版有下列已知問題：
| 問題 | 描述 | 降低 |
|---|---|---|
| DNAT 支援私人的 IP 位址僅限於標準和進階版本 | Azure 防火牆私人 IP 位址上的 DNAT 支援僅適用於標準和進階防火牆版本，不適用於基本版本。 | 無 |
| 設定私人 IP DNAT 規則時，不支援 Azure 防火牆解除配置和配置流程 | 設定私人 DNAT 規則時，Azure 防火牆配置程式會失敗 | 1. 解除配置 Azure 防火牆 2。 刪除所有私人IP DNAT規則 3。 配置 Azure 防火牆，並等到私人 IP 填入 4。 使用適當的私人IP位址重新設定私人IP DNAT規則 |
| 非 TCP/UDP 通訊協定 (例如 ICMP) 的網路篩選規則，不適用於流向網際網路的流量 | 非 TCP/UDP 協定的網路篩選規則無法在使用 SNAT 時適用於您的公用 IP 位址。 在輪輻子網路與 VNet 之間支援非 TCP/UDP 通訊協定。 | Azure 防火牆會使用 Standard Load Balancer，目前針對 IP 通訊協定不支援 SNAT。 我們正在探索在未來版本中支援網際網路繫結流量的非 TCP/UDP 通訊協定的選項。 |
| 解除配置 Azure 防火牆，然後再次配置時，可能會為其指派新的私人 IP 位址 | 在 Azure 防火牆的解除配置和配置流程之後，會從 Azure 防火牆子網路動態指派私人 IP 位址。 當指派與前一個不同的新私人 IP 位址時，會導致路由問題。 | 您需要使用新的專用IP地址重新配置現有的使用者定義路由（UDR）。 正在研究一項解決方案，以確保在配置過程後仍能保留私人IP地址。 |
| 子防火牆原則不會從父原則繼承 DNS 設定。 | 當您變更父防火牆政策中的 DNS 設定時，連結至它的子政策可能無法解析其規則中的網域名稱。 | 直接在每個子原則上設定 DNS 設定，而不是依賴父原則。 我們正在努力修復以允許繼承 DNS 設定。 |
| 對於 ICMP 缺少 PowerShell 和 CLI 支援 | Azure PowerShell 和 CLI 不支援在網路規則中將 ICMP 作為有效的通訊協定。 | 您仍可透過入口網站和 REST API 來使用 ICMP 作為通訊協定。 我們正努力盡快在 PowerShell 和 CLI 中新增 ICMP。 |
| FQDN 標籤需要設定「通訊協定:連接埠」 | 具有 FQDN 標籤的應用程式規則需要「連接埠: 通訊協定」定義。 | 您可以使用 https 作為「連接埠:通訊協定」值。 我們正在努力將 port： protocol 欄位設為使用 FQDN 標籤時的選擇性。 |
| 不支援將防火牆移動到不同的資源群組或訂用帳戶 | 不支援將防火牆移動到不同的資源群組或訂用帳戶。 | 支援此功能已列入我們的藍圖。 若要將防火牆移動到不同的資源群組或訂用帳戶，您必須刪除目前的執行個體，並將其重新建立在新的資源群組或訂用帳戶中。 |
| 威脅情報警示可能會被隱藏 | 目的地為 80/443 的網路規則，可供輸出篩選遮罩處理設定為僅限警示模式的威脅情報警示。 | 使用應用程式規則建立 80/443 的輸出篩選。 或者，將威脅情報模式變更為 [警示並拒絕]。 |
| 使用安全的虛擬中樞，可用性區域只能在部署期間進行設定。 | 在部署具有安全虛擬中樞的防火牆之後，您無法設定可用性區域。 | 依據設計。 |
| 傳入連線上的 SNAT | 傳入 DNAT 規則一律會變更傳回流量的來源 IP 位址。 | 若要追蹤 Web 流量的原始用戶端 IP，請設定用戶端或 Proxy 伺服器，以在 XFF 標頭中包含原始 IP。 Azure 防火牆會在 XFF 標頭中保留這些 IP 位址，並在處理 Web 流量規則時將防火牆 IP 新增至 XFF 標頭。 |
| SQL FQDN 篩選支援僅限於 Proxy 模式 (連接埠 1433) | 針對 Azure SQL Database、Azure Synapse Analytics 和 Azure SQL 受控執行個體： 只有 Proxy 模式才支援 SQL FQDN 篩選 (連接埠 1433)。 針對 Azure SQL IaaS： 如果您使用非標準連接埠，您可以在應用程式規則中指定這些連接埠。 |
在重新導向模式中使用 SQL 時 (這是從 Azure 內連線時的預設值)，您可以改為使用 SQL 服務標籤作為 Azure 防火牆網路規則的一部分來篩選存取。 |
| TCP 通訊埠 25 上的輸出 SMTP 流量會遭到封鎖 | Azure 平台會封鎖在 TCP 連接埠 25 上直接傳送至外部網域的輸出電子郵件訊息（例如 outlook.com 和 gmail.com）。 封鎖埠 25 上的輸出 SMTP 流量是 Azure 中的預設平臺行為。 Azure 防火牆不會引入任何更具體的限制。 |
請使用已驗證的 SMTP 轉送服務，這類服務通常會透過 TCP 通訊埠 587 連線，但也支援其他連接埠。 如需詳細資訊，請參閱Azure 中的外寄 SMTP 連線問題疑難排解。 另一個選項是在標準 Enterprise 合約 (EA) 訂用帳戶中部署 Azure 防火牆。 EA 訂用帳戶中的 Azure 防火牆可以使用輸出 TCP 連接埠 25 與公用 IP 位址通訊。 它可能適用於其他訂閱類型，但不保證。 對於虛擬網路、VPN 和 Azure ExpressRoute 等私人 IP 位址，Azure 防火牆支援 TCP 通訊埠 25 上的輸出連線。 |
| SNAT 連接埠耗盡 | Azure 防火牆目前針對每個後端虛擬機器擴展集執行個體的每個公用 IP 位址，支援 2,496 個連接埠。 根據預設，會有兩個虛擬機器擴展集執行個體。 因此，每個流程有 4,992 個埠（目的地 IP、目的地埠和通訊協定 （TCP 或 UDP）。 防火牆最多可擴大至 20 個執行個體。 | SNAT 埠耗盡是平臺限制。 針對易受到 SNAT 耗盡影響的部署，您可以為 Azure 防火牆部署至少設定五個公用 IP 位址以緩解限制。 新增更多公用 IP 位址會將可用的 SNAT 連接埠增加五倍。 從 IP 位址前綴分配以簡化下游權限。 如需更長久的解決方案，您可以部署 NAT 閘道來克服 SNAT 連接埠限制。 虛擬網路部署支援 NAT 閘道部署。 如需詳細資訊，請參閱使用 Azure 虛擬網路 NAT 調整 SNAT 連接埠的規模。 |
| 啟用強制通道時不支援 DNAT | 因為非對稱式路由，部署了強制通道的防火牆無法支援來自網際網路的輸入存取。 | 由於非對稱路由，強制隧道缺乏DNAT支持是設計使然。 輸入連線的傳回路徑會通過內部部署防火牆，而防火牆未能察覺已建立的連線。 |
| 視您的 FTP 伺服器設定而定，輸出被動 FTP 可能不適用於具有多個公用 IP 位址的防火牆。 | 被動 FTP 會針對控制和資料通道建立不同的連線。 當具有多個公用 IP 位址的防火牆傳送輸出資料時，會為來源 IP 位址隨機選取其中一個公用 IP 位址。 視您的 FTP 伺服器設定而定，當資料和控制通道使用不同的來源 IP 位址時，FTP 可能會失敗。 | 已規劃了明確的 SNAT 組態。 在此同時，您可以將 FTP 伺服器設定為接受來自不同來源 IP 位址的資料和控制通道 (請參閱 IIS 的範例)。 或者，在遇到 FTP 連線問題時，請考慮使用單一 IP 位址。 |
| 視您的 FTP 伺服器設定而定，可能無法使用輸入被動 FTP | 被動 FTP 會針對控制和資料通道建立不同的連線。 Azure 防火牆上的輸入連線會透過 SNA 轉譯到其中一個防火牆私人 IP 位址，以確保路由對稱。 視您的 FTP 伺服器設定而定，當資料和控制通道使用不同的來源 IP 位址時，FTP 可能會失敗。 | 原始來源 IP 位址保留方法正在研究中。 在此同時，您可以將 FTP 伺服器設定為接受來自不同來源 IP 位址的資料和控制通道。 |
| 當 FTP 用戶端必須透過網際網路連線到 FTP 伺服器時，主動 FTP 無法運作。 | 作用中 FTP 會利用 FTP 用戶端的 PORT 命令，將 FTP 伺服器導向要用於資料通道的 IP 和連接埠。 PORT 命令會使用無法變更的用戶端專用 IP。 往返 Azure 防火牆的用戶端流量在進行網際網路型通訊時經過 NAT，因此 FTP 伺服器會將 PORT 命令視為無效。 | 主動FTP故障是主動FTP與客戶端NAT一起使用時的一般限制。 |
| NetworkRuleHit 計量缺少通訊協定維度 | ApplicationRuleHit 計量允許篩選型的通訊協定，但對應的 NetworkRuleHit 計量中缺少這項功能。 | 我們正在調查提供修正程式的可能性。 |
| 64000 到 65535 之間的連接埠的 NAT 規則不受支援 | Azure 防火牆允許網路和應用程式規則使用 1-65535 範圍中的任何連接埠，不過 NAT 規則只支援 1-63999 範圍中的連接埠。 | NAT規則埠的限制是當前限制。 |
| 組態更新平均可能需要 5 分鐘 | Azure 防火牆組態更新平均可能需要三到五分鐘，而且不支援平行更新。 | 我們正在調查提供修正程式的可能性。 |
| Azure 防火牆會使用 SNI TLS 標頭來篩選 HTTPS 和 MSSQL 流量 | 如果瀏覽器或伺服器軟體不支援伺服器名稱指示 (SNI) 擴充，您就無法透過 Azure 防火牆連線。 | 如果瀏覽器或伺服器軟體不支援 SNI，您或許能夠使用網路規則 (而非應用程式規則) 來控制連線。 如需可支援 SNI 的軟體，請參閱伺服器名稱指示。 |
| 無法使用入口網站或 Azure Resource Manager (ARM) 範本新增防火牆原則標籤 | Azure 防火牆原則具有修補支援限制，將會防止您使用 Azure 入口網站或 ARM 範本新增標籤。 系統會產生下列錯誤：無法儲存資源的標籤。 | 我們正在調查提供修正程式的可能性。 或者，您可以使用 Azure PowerShell Cmdlet Set-AzFirewallPolicy 來更新標籤。 |
| 目前不支援 IPv6 | 如果您將 IPv6 位址新增至規則，防火牆將會失敗。 | 只可使用 IPv4 位址。 IPv6 支援仍在調查中。 |
| 不支援使用 ARM 範本移除 RuleCollectionGroups。 | 使用 ARM 範本移除 RuleCollectionGroup 不受支援，且會導致失敗。 | 使用 ARM 範本移除 RuleCollectionGroups 不是支援的作業。 |
| 允許「所有」 (*) 的 DNAT 規則一律為 SNAT 流量。 | 如果 DNAT 規則允許 任何 （*） 作為來源 IP 位址，則隱含網路規則會比對 VNet-VNet 流量，並一律對流量進行 SNAT。 | DNAT 規則中 任何 來源的自動 SNAT 行為是目前的一項限制。 |
| 不支援將 DNAT 規則新增至具有安全性提供者的安全虛擬中樞。 | 當您將 DNAT 規則新增至具有安全提供者的安全虛擬中樞時，會為傳回的 DNAT 流量提供非同步路由，該路由會傳送至安全提供者。 | 不支援。 |
| 建立超過 2,000 個規則集合時發生錯誤。 | NAT/應用程式或網路規則集合的數量上限為 2000 個 (Resource Manager 限制)。 | 2,000 個規則集合數量限制是當前的限制。 |
| 無法使用新建立的公用 IP 位址部署具備可用性區域的防火牆 | 在部署具有 Azure 可用性區域的防火牆時，您無法使用新建立的公用 IP 位址。 | 請先建立新的區域備援公用 IP 位址，然後在防火牆部署期間指派先前建立的 IP 位址。 |
| 跨租用戶案例不支援將公用 IP 位址與 Azure 防火牆產生關聯。 | 如果您在租用戶 A 中建立公用 IP 位址，則無法將它與部署在租用戶 B 中的防火牆產生關聯。 | 沒有。 |
| Azure 防火牆後方的 VM 無法使用防火牆的公用 IP 連線到 DNAT 規則目的地 | 當 VM 透過 Azure 防火牆路由傳送流量，並嘗試使用防火牆的公用 IP 位址連線到設定有 DNAT 規則的資源時，連線會失敗。 連線失敗的原因是 Azure 防火牆不支援將內部 VM 的流量釘選到防火牆自己用於 DNAT 規則目的地的公用 IP 位址。 | 目前正在開發此限制的解決方案。 |
Azure 防火牆進階版已知問題
附註
適用於標準版的任何問題也適用於進階版。
Azure 防火牆進階版有下列已知問題：
| 問題 | 描述 | 降低 |
|---|---|---|
| HTTPS 中 FQDN 解析的 ESNI 支援 | HTTPS 交握不支援加密的 SNI。 | 目前只有 Firefox 透過自訂設定支援 ESNI。 建議的解決方法是禁用 ESNI 功能。 |
| 不支援用戶端認證驗證 | 用戶端憑證可用來組建用戶端與伺服器之間的相互識別信任。 用戶端憑證會在 TLS 交涉期間使用。 Azure 防火牆會與伺服器重新交涉連線，而且無法存取用戶端憑證的私密金鑰。 | 無 |
| QUIC/HTTP3 | QUIC 是 HTTP 新的主要版本。 這是基於 80 (PLAN) 和 443 (SSL) 的 UDP 型通訊協定。 不支援 FQDN/URL/TLS 檢查。 | 將 UDP 80/443 設定為網路規則。 |
| 未受信任的客戶簽名憑證 | 防火牆從內部網路型網頁伺服器接收客戶簽署的憑證時，不會信任這些憑證。 | 我們正在調查提供修正程式的可能性。 |
| IDPS 顯示錯誤的來源 IP 位址，以取得 HTTP 警示，而沒有 TLS 檢查 | 當 IDPS 針對公用 IP 位址的純文字 HTTP 流量產生警示時，它會顯示內部 IP 位址，而不是原始來源 IP 位址。 | 我們正在調查提供修正程式的可能性。 |
| 憑證傳播 | 在防火牆上套用 CA 憑證之後，憑證可能需要 5-10 分鐘才會生效。 | 我們正在調查提供修正程式的可能性。 |
| TLS 1.3 支援 | TLS 1.3 部分支援。 從用戶端到防火牆的 TLS 通道是以 TLS 1.2 為基礎，而從防火牆到外部 Web 服務器的 TLS 通道是以 TLS 1.3 為基礎。 | 我們正在調查提供更新的可能性。 |
| TLSi 中繼 CA 憑證到期 | 在某些獨特的情況下，中繼 CA 憑證會在原始到期日之前兩個月到期。 | 在原始到期日之前兩個月更新中繼 CA 憑證。 我們正在調查提供修正程式的可能性。 |