騰訊雲企業帳號充值 騰訊雲CLB負載均衡轉發失敗怎麼辦

一、先把現象說清楚：轉發失敗到底是什麼

很多故障不是「CLB 壞了」，而是某條鏈路中的一個環節不匹配：健康檢查沒通、后端實際不可達、協議或端口不對、證書/Host 不符合、或安全策略擋住了回包。你要做的第一件事，是把「失敗」拆成可觀測的現象。

常見現象大致分四類：

• 騰訊雲企業帳號充值 客戶端直接超時：通常意味著請求到 CLB 了，但后端沒有回包，或路由/安全策略阻斷。
• 返回 502/504：通常意味著 CLB 或后端在轉發過程中出錯，或超時。
• 只有部分請求成功：可能是會話/源 IP/權重策略導致的分流差異，或某些后端節點異常。
• 切換后立即失效：例如更新了 Listener、證書、轉發規則或安全組後突然出問題。

建議你在一開始就記下四個信息：故障時間點、涉及的域名/URL、返回碼/錯誤關鍵字、以及影響範圍（全站或局部、所有用戶或特定區域/網段）。後面每一步排查都能用這些信息縮小範圍。

二、基本排查順序：先看「還有沒有可用后端」

CLB 的本質是把入站流量分發到后端。若转发失败，優先確認是否存在「可用的后端實例」。在很多案例中，根因其實是健康檢查没通过，導致 CLB 從邏輯上找不到可用目標。

1. 檢查健康檢查狀態（最常見）

到控制台查看 CLB 相關的目標組/后端實例列表，重點看健康檢查是否為「Healthy」。若全部是 Unhealthy，CLB 就只能在轉發時失敗或超時。

健康檢查不通的原因往往有三種：

• 騰訊雲企業帳號充值 探測路徑/端口不對：Listener 配置轉發到 80，但健康檢查探測的是 8080；或健康檢查使用的路徑與實際服務路由不一致。
• 服務尚未啟動或只在內網监听：例如容器只在 127.0.0.1 綁定；或僅開放內网地址，外部探測失敗。
• 健康檢查被安全策略擋住：安全組或 NACL 對探測端口/來源不允許；或后端防火牆限制了探測来源。

實操建議：先把健康檢查設定和你實際服務的「協議、端口、路徑、返回內容」一一對照。路徑如果要求特定 header（例如某些 API 只有在帶特定 Host 才返回正常），健康檢查也可能失敗。

2. 看后端是否被限流或連接耗盡

即使健康檢查為 Healthy，也不代表每次轉發都能成功。下一步看后端資源是否在高負載下無法建立連接或長時間不回應。

常見指標：

• 后端服務的 CPU/內存飙升，導致處理超時。
• 后端的連接數接近上限（例如 OS 文件描述符不足、連接池耗盡）。
• 騰訊雲企業帳號充值 后端出現大量 5xx 或明顯延遲。

你需要把「CLB 轉發失敗」和「后端自身超時」分開看。若后端日志顯示大量請求進來但處理超時，問題更多在應用；若后端壓根沒收到請求，問題更可能在前置（安全組/路由/轉發規則）或協議不匹配。

三、轉發規則與端口匹配：很多事故就卡在這裡

CLB 的轉發不是玄學，它由 Listener、協議、端口、以及轉發到的后端端口共同決定。任何一個不一致都可能導致「連上了但不能成功建立應用層通信」。

1. Listener 協議與實際服務協議是否一致

常見錯配：

• 你配置了 HTTP 監聽，但后端實際只支持 HTTPS；或反過來。
• 你配置了 TLS 終止在 CLB，但后端仍期待 TLS，導致握手失敗。
• 你把 HTTP/HTTPS 路由混在同一個規則下，造成部分請求進錯目標。

這類錯配的表現通常是 502、握手錯誤、或后端明明在跑卻「看不到有效請求」。建議你用同一套協議模型去核對：CLB 到后端到底是 HTTP 還是 HTTPS？若是 HTTPS，是否有證書校驗需求？Host/SNI 是否要求匹配？

2. 轉發到的后端端口是否正確

最直觀但也最容易被忽略。你可能在容器內暴露了 8080，但安全組放行的是 80；或 CLB 轉發到 80，實際服務在 8080。

檢查方法很簡單：在后端節點上確認服務監聽端口，並對照 CLB 的目標端口配置。若你用了容器映射或多服務共用節點，也要確認是「節點端口」還是「容器端口」。

3. 路由規則（路徑/域名/重寫）是否一致

如果你在 CLB 上用到了路徑匹配、域名匹配、或 header 重寫，一定要核對規則是否在最近的變更中被調整。很多「轉發失敗」只影響特定 URL，例如某個路徑返回 404 或 502，而其他路徑正常。

這通常意味著：請求確實到 CLB 了，但落到了錯的轉發規則，導致后端端點不存在、或后端返回錯誤但 CLB 依然把它當作失敗。

四、安全組與網路可達性：從「能不能連」開始

當健康檢查不通或后端看不到請求時，網路層問題的概率會很高。你要從「CLB 到后端」的可達性出發，逐層排除。

騰訊雲企業帳號充值 1. 安全組是否放行了必需的方向

安全組通常包含入站和出站規則。CLB 轉發到后端，至少需要后端能接收指定端口的入站；同時也要確保回包能返回到源。

常見錯誤：

• 只放行了入站，沒放行回程所需的出站（或反之）。
• 放行了端口但限制了來源 IP/安全組 ID，與 CLB 的來源不一致。
• 變更了 VPC、子網或節點安全策略後，舊規則不再適用。

建議做法：把 CLB 與后端的安全策略用「端口+來源」的方式重新整理一遍，確認沒有因為來源變更而被拒。

2. 路由（Route）與子網是否匹配

如果 CLB 和后端不在同一網段或存在跨可用區/跨子網，路由表可能是下一個雷點。典型情況是：后端能在自己節點網段通信，但從 CLB 所在網段發起的流量到不了。

此時你會看到大量超時，且健康檢查可能也不通。排查時要確認：

• VPC 内路由是否允許從 CLB 所在子網到后端子網的流量。
• 是否存在錯誤的路由指向或缺失的路由條目。
• 是否啟用了額外的網路安全設備（如防火牆/NAT）造成策略中斷。

五、TLS/HTTP 行為細節：看似小事，卻會導致整段轉發失敗

在涉及 HTTPS、WAF、或多域名證書的情況下，轉發失敗常常不是因為「證書過期」，而是因為「握手與路由條件不匹配」。

1. SNI/Host 匹配是否正確

當使用同一個 CLB 服務多個域名時，CLB 或后端可能依賴 Host（以及 SNI）選擇對應的站點/證書。若 Host 不匹配或后端不接受該 Host，可能出現握手失敗或返回非預期錯誤。

如果你最近調整了域名解析、證書內容或站點配置，立刻回看這些變更。

2. 設置 HTTP 重定向與健康檢查的互相影響

很多網站啟用了 HTTP 到 HTTPS 的強制跳轉。若健康檢查使用 HTTP 探測但后端要求跳轉，探測可能拿到 301/302，若你的健康檢查只認可 200，就會判定不健康。

解法通常是兩個方向：要麼讓健康檢查探測符合預期的狀態碼，要麼提供獨立的健康檢查端點（例如 /healthz）並返回固定成功結果。

3. 超時參數是否合理

轉發失敗的另一個常見原因是超時設定不合理：后端偶爾需要更長時間（比如慢查詢、冷啟動），但 CLB 的轉發超時偏小，導致大量 504。

此時要把視角從「網路是否通」切到「應用處理時間」。如果后端在超時前就能返回 200，那問題在后端；如果后端根本不返回，那問題在后端瓶頸或連接建立。

六、如何用日誌把問題定位到「哪一段在失敗」

排查最怕的是你不停猜，最後猜不到。要做的是：讓每一步都回答同一個問題——請求走到哪裡了？在哪裡變成失敗？

1. 先看 CLB 日誌/指標中的錯誤類型

CLB 通常能提供一些可用的觀測：轉發成功率、失敗原因、延遲、以及后端選擇情況。你可以用它快速分辨：

• 是健康檢查導致沒有后端可選？
• 是建立連接失敗？
• 是上游響應超時？

當你能把錯誤原因聚到一類，后續排查就不會散。

2. 后端應用日志：確定是否真的收到請求

在后端服務上，查詢相同時間窗口内的請求日志。你要的是「是否收到請求」以及「請求是否完整」。

• 如果后端日志完全沒有這些來源的请求，通常是安全組/路由/轉發規則不通。
• 如果日志能看到請求進來，但處理耗時、異常或返回 5xx，那就是应用層問題。
• 騰訊雲企業帳號充值 如果日志看到握手或解析錯誤（例如 TLS/HTTP 解析失敗），那多半是協議或 header 匹配錯誤。

3. 用同一客戶端重現：降低不確定性

選一個容易重現的客戶端（或同一測試機），反覆測試同一 URL。並在每次變更（例如調整安全組、修改端口、更新證書）後重新測試。不要同時改太多項，否則你不知道哪個改動帶來了效果。

七、修復方案：按根因給你可執行的處理動作

下面把最常見根因對應到處理動作，讓你能直接落地。

場景 A：健康檢查不通

• 核對健康檢查協議/端口/路徑是否和服務一致。
• 確保健康檢查端點能快速返回成功（建議返回 200，且不要依賴外部依賴，如資料庫）。
• 檢查安全組是否允許 CLB 探測來源到后端端口。
• 檢查后端是否只在內網监听或綁定了错误的網卡。

場景 B：健康檢查通，但轉發仍失敗或 502/504

• 檢查后端連接是否耗盡（文件描述符、連接池、最大並發）。
• 核對轉發到的后端端口是否正確，避免「端口通但不是應用端口」。
• 調整超時與重試策略：若業務允許，延長超時；若不允許重試，避免雪崩。
• 檢查后端是否有 TLS 期待與 CLB 協議設置不一致。

騰訊雲企業帳號充值 場景 C：只影響部分域名/部分 URL

• 檢查 Listener 轉發規則的域名/路徑匹配條件。
• 檢查 Host/SNI/證書是否正確。
• 檢查 HTTP 到 HTTPS 的跳轉是否影響健康檢查端點或路由。

場景 D：只在切換或發布後出現

• 回看發布內容：是否改了監聽端口、綁定地址、或對外暴露策略。
• 容器/服務啟動順序是否導致短時間不可用。可引入就緒探針（readiness）或延遲放量。
• 若使用藍綠部署，確認新舊環境的安全組、證書與轉發規則同步完成。

八、預防清單：把問題變成可預測的工程

事故往往不是突然發生，而是可用性指標、變更流程與觀測不足逐步累積的結果。你可以用以下清單提升穩定性。

1. 健康檢查端點設計

• 健康檢查應當輕量、快速、可預期，不依賴外部慢服務。
• 返回碼要明確，並與健康檢查可配置條件一致。
• 若使用重定向，確保健康檢查使用的 URL 不會跳轉到不可預期的地方。

2. 監控要把「失敗原因」拆開看

• 監控健康檢查狀態變化（Healthy/Unhealthy 的比例、持續時間）。
• 監控后端延遲與錯誤率（應用 5xx、超時、慢請求）。
• 監控連接數、佇列長度與資源飽和（CPU、内存、FD）。
• 監控 CLB 轉發成功率與錯誤碼分佈。

3. 變更流程要可回滾、可對照

• 騰訊雲企業帳號充值 每次只改一類配置（端口/協議/安全策略/證書/路由），避免混合變更難定位。
• 準備清晰的回滾步驟：例如恢復上一版 Listener 規則或安全組。
• 發布前在測試環境驗證健康檢查與協議行為，尤其是 HTTPS 與多域名場景。

4. 讓排查更快：建立「排查模板」

你可以把本文的排查順序固化成一個內部模板：先健康檢查，再轉發規則端口協議，再安全組路由，再日誌定位。每次事故都按模板走，能顯著縮短恢復時間。

九、結語：把 CLB 轉發失敗拆成可驗證假設

「騰訊雲 CLB 轉發失敗怎麼辦」的答案並不是一招修好，而是一套可驗證的排查路徑。當你把現象拆分（超時還是 502/504、全量還是局部），再按順序核對（健康檢查、端口與協議、網路可達性、TLS/Host 行為、以及日志定位），你就能把問題從「看起來很複雜」縮到「很快知道是哪一段不對」。

把這套思路用在每次故障處理中，你會發現 CLB 的穩定性很大程度取決於配置一致性和可觀測性。當工程做到位，真正的故障就只會在小範圍內發生，而且更容易快速修復。