騰訊雲帳號代開服務 如何在騰訊雲CLB上配置SSL卸載

第一章：先想清楚你要解決什麼

SSL 卸載（SSL Offloading）這件事，看起來只是把證書丟到負載均衡上，實際上牽涉的是流量在「客戶端—CLB—後端」三段路徑的加密策略。你需要先確認：你要的是「把 HTTPS 解密工作交給 CLB」嗎？那後端與 CLB 之間要不要繼續加密？不同選擇會影響安全性、性能、運維成本與故障排查方式。

在騰訊雲 CLB 上做 SSL 卸載，通常意味著：外部使用者透過 HTTPS（443）訪問時，由 CLB 負責 TLS 握手與證書驗證；而後端服務則依你的配置可以用 HTTP 明文接收，或仍走 HTTPS。大多數企業在性能與簡化運維之間取得平衡：對外保證加密，對內在內網使用 HTTP（或使用私有網段+安全策略）以降低後端解密壓力。

接下來的步驟，我會以「你已經有一個後端服務在某個內部端口提供 HTTP/HTTPS」為前提，完整帶你把 CLB 的 HTTPS 入口、證書綁定、轉發規則和驗證流程串起來。

第二章：準備工作不可省

2.1 確定域名與證書類型

SSL 配置的第一個核心是域名。你需要確定：外部訪問的域名（例如 www.example.com）與證書上包含的名稱一致。若使用了通配符證書，請確認域名匹配規則符合你預期；若使用了多域名證書（SAN），也要確認你實際對外的域名包含在證書範圍中。

證書來源通常有兩類：一是你已經在騰訊雲上準備了證書（或可匯入），二是你有自己的證書文件（含私鑰）。不管來源怎樣，CLB 在配置時通常需要：證書內容（Cert）、私鑰（Key），以及必要的中間證書鏈（若你的部署要求）。

如果你缺私鑰或缺中間證書，最常見的後果是：握手失敗、瀏覽器顯示不受信任、或部分客戶端報證書鏈不完整。這類問題一旦發生，排查就會變得很耗時，所以建議你在正式上線前先在測試環境把握手打通。

2.2 明確後端協議：HTTP 還是 HTTPS

配置 SSL 卸載時，你可以讓 CLB 到後端的轉發使用 HTTP 或 HTTPS：

• HTTPS（端到端）：客戶端—CLB—後端都加密。優點是內部鏈路也有加密，缺點是後端仍需要處理 TLS，資源消耗較高，證書管理複雜度也上升。
• HTTP（典型卸載）：客戶端—CLB 加密，CLB—後端明文。優點是卸載收益明顯，後端壓力小；缺點是你必須確保後端鏈路在網路層面是可信的（例如內網、專有網段、嚴格安全組規則）。

在企業常見場景中，若後端服務位於私有網段，且安全組/ACL 嚴格限制來源，使用 HTTP 作為卸載目標是合理的。反之，如果後端跨網域或鏈路不受控，那就更應該選擇後端 HTTPS，至少確保風險可控。

2.3 準備好後端健康檢查

CLB 配置不只在「接收請求」；它還會根據健康檢查決定流量往哪些實例轉發。SSL 卸載後端若使用 HTTP，你的健康檢查通常走 HTTP；若後端使用 HTTPS，就要相應調整健康檢查的協議與埠。

建議你提前確定兩件事：第一，健康檢查路徑（例如 /health）是否存在且返回狀態碼正確；第二，健康檢查使用的協議是否能在網路層通過（安全組、路由、NAT 等）。很多人上線後才發現「TLS 配好了但流量沒進後端」，原因往往不是 TLS，而是健康檢查沒通。

第三章：在 CLB 上配置 HTTPS 與證書綁定

具體操作入口會因為騰訊雲控制台版本略有差異，但主流程大同小異：你需要在 CLB 的監聽（Listener）層新增 HTTPS 監聽，並把你準備好的證書綁到該監聽上；然後配置轉發到目標群組（Target Group）或後端實例。

3.1 找到對應的 CLB 實例與網路類型

首先進入騰訊雲控制台，定位到你的 CLB。確保它的網路類型、所屬 VPC、子網與你的後端實例位於相同的網路環境中。SSL 卸載本身不要求你特別修改網路，但「端口能不能到達後端」取決於路由與安全策略。

如果你使用的是內網 CLB 或公開 CLB，外部訪問入口與安全組策略也會不同。你不一定要先改所有設定，但至少要確保：外部 443/80 的流量能到 CLB，CLB 能到後端服務埠。

3.2 新增或修改監聽：HTTPS 443

在 CLB 的「監聽」或「Listener」配置區塊新增一條監聽規則，核心字段通常包括：

• 協議：選擇 HTTPS。
• 端口：一般使用 443。
• 證書：選擇你已匯入/準備好的證書。
• 轉發目標：把該監聽的流量轉發到對應的後端（目標群組）與後端埠。

你需要注意的是「後端埠」與你實際部署服務的端口一致。很多配置錯誤不是在 TLS，而在端口映射：例如你後端服務其實跑在 8080，但你在 CLB 裡填成 80，結果請求會被轉到錯的地方，表面上可能看起來像「SSL 正常但頁面打不開」。

3.3 配置轉發策略與會話行為

在監聽與轉發之間，CLB 通常支持基於條件（例如路徑/主機名）轉發，以及會話保持（若你有需要）。SSL 卸載時，會話保持不一定必須，但若你的業務依賴 Session（例如純 Cookie 未做共享），那你需要考慮粘性會話或後端共享 Session 的方式。

若你的服務是無狀態（例如基於 JWT 或 token），那通常更簡單。你只要確保後端健康檢查通過、轉發埠正確、以及證書有效即可。

3.4 （可選）新增 HTTP 80 的重定向

實務中常見做法是：保留 80 作為入口，並把 HTTP 重定向到 HTTPS，或直接讓 80 的流量以 HTTP 形式提供服務。重定向通常更符合安全與一致性要求。

如果你希望 80 自動跳到 443，你需要在 CLB 層啟用對應的重定向功能（若控制台提供），或在後端由應用負責重定向。選擇哪種取決於你想把控制邏輯放在哪一層。若你只是希望盡快上線，後端重定向更彈性；若你想在網關層統一規則，CLB 端重定向更一致。

第四章：檢查安全組與端口放行

騰訊雲帳號代開服務 TLS 配置成功與否，有很大一部分由網路策略決定。即使你證書綁定完全正確，只要 CLB 到後端的埠被阻擋，你也會看到「連線超時」或「502/504 類似錯誤」。因此你需要系統性檢查三個方向：

• 外部到 CLB：安全組或 NACL 允許 443（以及可選 80）入站。
• CLB 到後端：安全組允許 CLB 的來源訪問後端服務埠。
• 健康檢查通道：CLB 用於健康檢查的協議與端口也要通過安全策略。

建議你在測試期先用最小化變更：確保 CLB 與後端間的連通性，再回到 TLS。這樣你能更快定位問題屬於哪一層。

第五章：驗證 SSL 卸載是否真的生效

配置完成後，不要急著在瀏覽器打開就算過關。你應該用更可控的方式驗證：TLS 握手是否成功、證書是否正確呈現、以及後端轉發是否符合你的設計。

騰訊雲帳號代開服務 5.1 用 curl 檢查握手與證書鏈

在你的測試機上，對 443 入口執行連線測試（例如查看證書主體、有效期、是否存在鏈問題）。如果證書不匹配，你會在客戶端看到名稱錯誤；如果鏈不完整，部分客戶端也可能提示不受信任。

當你看到握手成功後，再進一步檢查響應內容與狀態碼，確保不是「TLS 成功但路由錯」。

5.2 檢查後端是否收到正確的協議與來源信息

很多框架在處理「是否是 HTTPS」時依賴反向代理頭，例如 X-Forwarded-Proto、X-Forwarded-For。SSL 卸載後，後端看到的請求可能是 HTTP（若你選了典型卸載），此時如果應用沒有正確識別代理頭，可能會導致：

• 生成錯誤的絕對連結（http/https 混用）。
• 重定向邏輯失效。
• Cookie 的 Secure 屬性判斷錯誤。

因此你要在後端記錄或在測試環境確認代理頭的存在，並依照你的應用框架配置信任代理。這往往比你想像的更重要。

5.3 核對 CLB 的卸載行為：客戶端到 CLB 加密，CLB 到後端的選擇要吻合

你選了「CLB 到後端使用 HTTP」後，後端日誌中應該看到明文請求。如果你選的是「後端 HTTPS」，那後端應該能看到 HTTPS 連線（並且需要處理自己的證書或啟用客戶端驗證的策略）。

此外，若你有在後端配置 WAF、限流或應用層的 TLS 限制，需要確認不會因為協議變更而造成誤判。

第六章：常見問題與排查路徑

SSL 卸載一旦出問題，通常不是單點故障，而是「證書—協議—端口—路由—健康檢查—應用識別」其中某一環節。下面我按常見現象整理排查思路。

6.1 瀏覽器顯示證書無效或名稱不匹配

這通常是證書主體與域名不一致。處理方式：核對你使用的請求域名是否在證書上；通配符證書是否匹配到子域名；是否存在你實際訪問的是 CNAME/別名域名但證書只覆蓋另一個主域名。

若你最近更新過證書，還要確認 CLB 是否已完成證書替換並針對監聽刷新生效。

6.2 curl 能連但頁面出錯（502/504/404）

這類問題多半不是 TLS，而是轉發或健康檢查。

• 檢查監聽轉發的後端埠是否正確。
• 騰訊雲帳號代開服務 檢查目標實例是否健康，是否有實例被排除。
• 檢查應用是否只允許特定 Host、是否需要特定路徑。

如果你做了基於路徑的轉發規則，請確認規則匹配條件和你實際請求路徑一致。

騰訊雲帳號代開服務 6.3 健康檢查一直失敗，導致沒有流量落到後端

健康檢查失敗的原因常見有：端口不通、安全組阻擋、健康檢查路徑不存在、健康檢查協議與後端協議不一致。你可以從 CLB 的健康檢查狀態開始，再逐步回看後端服務的日誌。

若你切換了後端協議（例如從 HTTPS 改成 HTTP），健康檢查的配置也要同步改，否則會出現「證書與轉發都配了但依然沒流量」的狀況。

6.4 後端重定向邏輯混亂，出現 http/https 來回跳

通常是應用沒有正確信任反向代理，導致它誤判「當前是否為 HTTPS」。你需要確認：

• CLB 是否會在請求頭中傳遞 X-Forwarded-Proto 等資訊。
• 應用框架是否已配置「信任代理」與正確讀取代理頭。
• 重定向規則是否基於正確的協議判斷。

解法往往在應用層，而不是繼續調整 TLS。

6.5 請求耗時變長，或吞吐下降

SSL 卸載後性能應該改善，但也可能因為其他因素引起變化，例如：後端仍在處理 TLS（你其實沒有真正卸載）、證書配置導致握手頻繁或協商過程較慢、或健康檢查間隔與超時設置不合理導致探測成本。

你可以從指標上看：CLB 的請求數、後端響應時間、錯誤碼比例，再結合應用日誌定位。不要一上來就懷疑證書本身。

第七章：上線建議與持續運維

把 SSL 卸載跑通只是第一步，更重要的是你要讓它能長期穩定。

7.1 證書到期管理要提前

證書到期是最常見的事故之一。你要建立更新提醒機制：證書到期前幾週完成導入與測試，確保 CLB 監聽關聯的證書能正常切換。建議你把證書更新流程標準化，讓團隊成員也能按同一套做法操作。

7.2 監控錯誤碼與握手失敗跡象

持續監控能更快發現問題：例如 4xx/5xx 比例上升、502/504 增多、健康檢查頻繁抖動，以及 TLS 握手失敗的趨勢。SSL 卸載常見的「突然崩」往往不是慢慢變差，而是某個環節失效後才在短時間內暴露。

7.3 針對不同域名與路徑使用合理的轉發規則

如果你同一個 CLB 上承載多個站點，請用清晰的規則避免維護困難。例如：按主機名（Host）或路徑（Path）拆分轉發；必要時使用不同監聽對應不同證書。這樣當你更新其中一個站點證書時，不會影響其他站點。

7.4 留意應用程式對代理的依賴

很多團隊在最初上線時沒把反向代理頭納入配置，等到出問題才補救。為避免反覆排查，你可以在上線前就把以下點確定下來：應用是否正確使用 X-Forwarded-Proto 判定安全鏈路；是否正確記錄客戶端 IP（X-Forwarded-For）；以及是否在生成跳轉連結時使用正確協議。

結語：把配置做成可控、可驗證的流程

在騰訊雲 CLB 上配置 SSL 卸載，最容易踩坑的不是某個按鈕怎麼點，而是你沒有把需求拆成可驗證的問題：證書是否匹配域名、監聽是否正確綁定、端口與轉發目標是否一致、健康檢查是否通過、後端是否按預期收到協議與代理頭。當你每一步都能用現象驗證（例如連線成功、證書正常、狀態碼正確、後端日誌符合預期），整個流程就會變得穩定而可維護。

騰訊雲帳號代開服務 如果你願意在測試環境先把「TLS 握手—轉發—應用識別」走通，再把相同配置逐步搬到正式環境，成功率通常會大幅提升。SSL 卸載的價值不只是把加密工作交出去，而是讓整套入口更一致、更安全，也更易於擴展。