本文協助您針對 Azure App Service 中的間歇性連線錯誤和相關的效能問題進行疑難排解。 這針對來源網路位址轉譯 (SNAT) 連接埠耗盡的問題，提供詳細資訊和疑難排解方法。 如果您在本文中的任何時間點需要更多協助，請連絡 Azure 社群支援的 Azure 專家。 或者，您可以提出 Azure 支援事件。 移至 Azure 支援 ，然後選取 [ 提交支援票證]。
徵兆
載入在 Azure App Service 上的應用程式和函式可能會顯示下列一或多個問題：
- 服務方案中所有或部分執行個體的回應時間很慢。
- 間歇性 5xx 或 閘道錯誤 。
- 逾時錯誤訊息。
- 無法連線到外部端點（例如 SQLDB、Service Fabric 或其他應用程式服務）。
原因
間歇性連線問題的主要原因是建立新的輸出連線時達到限制。 可能達到的限制包括：
- TCP 連線：可以進行的輸出連線數目有限制。 輸出連線的限制與使用的背景工作角色大小有關。
- SNAT 連接埠：Azure 中的輸出連線描述 SNAT 連接埠限制及其如何影響輸出連線。 Azure 與公用 IP 位址通訊時，使用來源網路位址轉譯 (SNAT) 和 Load Balancer (未向客戶公開)。 Azure App 服務上的每個執行個體最初都預先配置 128 個 SNAT 連接埠。 SNAT 連接埠限制影響對同一組位址和連接埠建立的連線。 如果應用程式對相混的位址和連接埠組合建立連線，則不會耗盡 SNAT 連接埠。 重複呼叫同一組位址和連接埠會耗盡 SNAT 連接埠。 一旦釋放埠，即可視需要重新使用埠。 只有在等候四分鐘后，Azure 網路負載平衡器才會從已關閉的連線回收 SNAT 埠。
當應用程式或函式快速開啟新的連線時，它們可以快速耗盡其預先配置的 128 個埠配額。 然後應用程式或函式就停滯，直到透過動態配置更多的 SNAT 連接埠，或重複使用回收的 SNAT 連接埠，而有新的 SNAT 連接埠可用為止。 如果您的應用程式用完 SNAT 埠，就會發生間歇性輸出連線問題。
避免問題
有幾個解決方案可讓您避開 SNAT 連接埠限制。 其中包含：
- 連線池：透過整合連線，您可以避免針對相同位址和埠的呼叫開啟新的網路連線。
- 服務端點：您對使用服務端點保護的服務沒有 SNAT 連接埠限制。
- 私人端點：您對使用私人端點保護的服務沒有 SNAT 連接埠限制。
- NAT 閘道：NAT 閘道提供 64k 個輸出 SNAT 連接埠，可供傳入流量的資源使用。
若要避免 SNAT 連接埠問題，您要避免對同一組主機和連接埠重複建立新連線。 連線集區是較明顯解決該問題的方式之一。
如果您的目的地是支援服務端點的 Azure 服務，您可以使用 區域虛擬網路整合 和服務端點或私人端點來避免 SNAT 埠耗盡問題。 當您使用區域虛擬網路整合並將服務端點放在整合子網上時，應用程式對這些服務的輸出流量將不會有輸出 SNAT 埠限制。 同樣地，如果您使用區域虛擬網路整合和私人端點，則不會有任何針對該目的地的 SNAT 出口埠問題。
如果目的地是 Azure 外面的外部端點，則使用 NAT 閘道會給您 64k 個輸出 SNAT 連接埠。 還給您專用的輸出位址，不與任何人共用。
可能的話，請改善程式碼來使用連線集區，徹底避免此情況。 不一定來得及變更程式碼以減輕此情況。 如果無法及時變更程式碼，請改採其他解決方案。 問題的最佳解決方案是盡可能結合所有解決方案。 至於其他情況，請嘗試對 Azure 服務和 NAT 閘道使用服務端點和私人端點。
若要深入瞭解降低 SNAT 埠耗盡的策略，請參閱 使用 SNAT 進行輸出連線。 在這些策略中，以下適用於 Azure App 服務上裝載的應用程式和函式。
使用連線池化
- 關於共用 HTTP 連線，請檢閱使用 HttpClientFactory 來共用 HTTP 連線。
- 如需 SQL Server 連線共用的相關資訊，請檢閱 SQL Server 連線共用 (ADO.NET)。
下列文章說明如何實作不同解決方案堆疊的連線共用。
節點
根據預設，Node.js的連線不會保持運作。
HTTP keep-alive
爪哇島
Java 資料庫連線能力 （JDBC） 連線共用
HTTP 連線共用
PHP
雖然 PHP 不支援連線共用，但您可以嘗試對後端伺服器使用持續性資料庫連結。
MySQL 伺服器
- 適用於較新版本的 MySQLi 連線
- 適用於較舊版本 PHP 的 mysql_pconnect
其他資料來源
Python（程式語言）
HTTP 連線共用
重複使用連線
如需在 Azure 函式中管理連線的詳細資訊指標和範例，請參閱 在 Azure Functions 中管理連線。
使用較不積極的重試邏輯
如需更多指引和範例，請參閱 重試模式。
使用keepalives重設輸出閒置逾時
如需實作 Node.js 應用程式的 Keepalives，請參閱 我的節點應用程式正在進行過多的輸出呼叫。
App Service 專屬的更多指引
- 負載測試應該以穩定的饋送速度模擬真實世界數據。 在真實世界壓力下測試應用程式和功能，可以事先識別並解決 SNAT 埠耗盡問題。
- 請確定後端服務可以快速傳回回應。 如需針對 Azure SQL Database 效能問題進行疑難排解，請檢閱使用 Intelligent Insights 針對 Azure SQL Database 效能問題進行疑難排解。
- 將 App Service 方案擴增到更多執行個體。 如需有關調整的詳細資訊，請參閱在 Azure App Service 中調整應用程式規模。 App Service 方案中的每個背景工作執行個體都配置有一些 SNAT 連接埠。 如果將使用量分散到更多執行個體，則每個執行個體的 SNAT 連接埠使用量可能低於對每個唯一遠端端點建議的限制，即 100 個輸出連線。
- 請考慮移至 App Service 環境 (ASE)，其中會分配單一輸出 IP 位址給您，而且連線和 SNAT 連接埠的限制較高。 在 ASE 中，每個執行個體的 SNAT 連接埠數目是以 azure 負載平衡器預先設定資料表為基礎。 例如，具有 1-50 個背景工作實例的 ASE 每個實例有 1,024 個預先配置埠，而具有 51-100 個背景工作實例的 ASE 則每個實例有 512 個預先配置埠。
因為輸出 TCP 限制是由背景工作角色的大小設定，避開限制較容易解決。 您可以查看沙箱跨 VM 數值限制 - TCP 連線中的限制
| 限制名稱 | 描述 | 小型 (A1) | 中型 (A2) | 大型 (A3) | 隔離層 (ASE) |
|---|---|---|---|---|---|
| 連線 | 整個 VM 的連線數目 | 1920 | 3968 | 8064 | 16,000 |
若要避開輸出 TCP 限制，您可以增加背景工作角色的大小，或水平擴增。
疑難排解說明
了解兩種輸出連線限制及應用程式在做什麼，應該會較容易疑難排解。 如果您知道應用程式頻繁呼叫相同的儲存體帳戶，您可能懷疑受到 SNAT 限制。 如果您的應用程式透過網際網路對端點建立大量呼叫，您可能會懷疑已達到虛擬機的限制。
如果您不夠了解應用程式的行為，而無法快速查明原因，App Service 中有一些工具和技術可幫助您判斷。
尋找 SNAT 連接埠配置資訊
您可以使用 App Service 診斷來尋找 SNAT 連接埠配置資訊，並觀察 App Service 網站的 SNAT 連接埠配置計量。 若要尋找 SNAT 連接埠配置資訊，請遵循下列步驟：
- 若要存取 App Service 診斷，請在 Azure 入口網站中瀏覽至您的 App Service Web 應用程式或 App Service 環境。 在提要欄中，選取 [ 診斷並解決問題]。
- 選取 [可用性和效能] 類別。
- 在類別下可用的圖格清單中，選取 [SNAT 連接埠耗盡] 圖格。 習慣上是保持低於 128。 真有需要的話，您仍然可以提交支援票證，支援工程師會為您從後端取得計量。
由於 SNAT 埠用量無法作為度量指標，因此無法根據 SNAT 埠使用量自動調整，或者根據 SNAT 埠分配指標設定自動調整。
TCP 連線和 SNAT 埠
TCP 連線和 SNAT 連接埠沒有直接關係。 TCP 連線使用偵測器包含在任何 App Service 應用程式的 診斷和解決問題 管理頁面中。 搜尋片語 TCP 連線 以尋找它。
- SNAT 埠僅用於外部網路流量，而 TCP 連線總數則包含本地環回連線。
- 如果不同流量的通訊協定、IP 位址或連接埠不同，則可以共用 SNAT 連接埠。 TCP 連線計量計算每個 TCP 連線。
- TCP 連線限制發生在背景工作執行個體層級。 Azure 網路輸出負載平衡不使用 TCP 連線計量來偵測 SNAT 連接埠限制。
- TCP 連線限制會在 沙箱跨 VM 數值限制 - TCP 連線中說明。
- 當新的輸出 TCP 工作階段從 Azure App Service 來源連接埠時新增，現有的 TCP 工作階段會失敗。 您可以使用單一 IP 或重新設定後端集區成員來避免衝突。
| 限制名稱 | 描述 | 小型 (A1) | 中型 (A2) | 大型 (A3) | 隔離層 (ASE) |
|---|---|---|---|---|---|
| 連線 | 整個 VM 的連線數目 | 1920 | 3968 | 8064 | 16,000 |
WebJobs 和資料庫連線
如果 SNAT 連接埠耗盡，而導致 WebJob 無法連線至 SQL Database，沒有計量可顯示每個 Web 應用程式流程開啟的連線數目。 若要找出有問題的 WebJob，請將幾個 WebJob 移到另一個App Service 方案，看看情況是否改善，還是其中一個方案仍有問題。 重複此流程，直到找出有問題的 WebJob 為止。