SCDN 完整接入與排錯
從源站準備、DNS 與證書到緩存、API 例外和故障回退，按可驗證的步驟完成 SCDN 接入。
本文目錄
首次接入先完成一個低風險域名的驗證，再逐批遷移。使用文中命令時，將示例值替換為您的實際配置。控制台入口為 SCDN 控制台。
接入前準備
準備能夠修改 DNS 的域名賬號、可用的 SCDN 套餐、源站管理權限和證書資料。賬號實名、線路適用條件及費用先查看 購買前提與計費說明。
| 需要記錄的實際值 | 從哪裏覈對 | 接入通過條件 |
|---|---|---|
| 域名、套餐和線路 | 當前網站配置與已購買套餐 | 域名額度、功能和線路符合本次業務需求 |
| 源站 IP 或獨立源站域名 | 服務器或雲平臺的實例信息 | 地址真實可用；獨立源站域名不會解析回本次 CDN |
| 回源協議、端口 | 源站監聽配置與 SCDN 網站配置 | 兩端一致，防火牆允許相應回源連接 |
| 回源 Host、HTTPS SNI | 源站虛擬主機、證書與實際回源配置 | 請求到達正確站點，TLS 握手使用正確名稱 |
| 訪問域名證書 | 證書詳情與實際 HTTPS 連接 | 覆蓋完整訪問域名，未過期，證書鏈完整 |
| CNAME 目標、舊解析和 TTL | SCDN 分配結果與 DNS 服務商記錄 | 每個域名都有記錄，能夠恢復之前的訪問路徑 |
| 登錄、API、回調和 WebSocket 路徑 | 業務路由與接口文檔 | 明確哪些不能緩存、不能接受瀏覽器挑戰 |
國內加速、海外優化和亞太優化線路目前均從標準版起包含 WAF，從基礎版起支持 WebSocket；個人版不支持這兩項，基礎版不支持 WAF。具體配置查看 SCDN 套餐表 和實際訂單。
第一步：覈對源站與回源
先確認源站可以處理真實業務請求，再配置 CDN。瀏覽器直接訪問 IP 成功，只能說明那一次訪問成功，不能證明所有 CDN 節點都能連接到正確站點。
| 項目 | 覈對方法 | 常見修正 |
|---|---|---|
| 源地址 | 與源站實例地址、域名解析結果逐一比對 | 使用真實源站地址，排除源站域名再次指向 CDN 形成循環 |
| 協議與端口 | 查源站 Web 服務實際監聽的協議和端口 | 源站只監聽 HTTP 時不能配置 HTTPS 回源；非標準端口先確認套餐支持 |
| 網絡放行 | 查安全組、防火牆和源站訪問日誌 | 向技術支持確認當前回源 IP 範圍，按需要放行指定端口並維護更新 |
| 回源 Host | 查源站虛擬主機綁定的域名、訪問日誌中的 Host | 確保請求匹配業務站點，而非默認站點 |
| HTTPS SNI | 查源站證書名稱與 TLS 虛擬主機配置 | 覈對 CDN 實際發送的 SNI、源站證書和回源校驗要求 |
| 多源站 | 逐臺檢查相同 URL 與業務版本 | 確認每臺源站健康，避免請求偶爾落到錯誤實例 |
Host 是 HTTP 請求中的站點名稱，SNI 是 TLS 握手階段使用的服務器名稱；把源地址改成 IP，並不等於這兩個值也應改成 IP。若控制台沒有顯示獨立 SNI 或回源 Host 設置，請提供源站域名與證書信息給技術支持確認實際行為，不要猜測默認值。
接入初期優先檢查回源端口、Host、協議和源站證書；遇到 504 應結合日誌判斷，不應僅憑狀態碼認定是攻擊或節點故障。接入初期 504 排查經驗
用真實域名測試源站
以下命令在 Windows 終端中運行。www.example.com 和 192.0.2.10 是示例域名與保留測試地址，請替換；Linux/macOS 可將 curl.exe 改為 curl、NUL 改為 /dev/null。
curl.exe --resolve www.example.com:80:192.0.2.10 -sS -D - -o NUL http://www.example.com/
curl.exe --resolve www.example.com:443:192.0.2.10 -sS -D - -o NUL https://www.example.com/
這兩條命令只在本次請求中指定連接地址，不修改 DNS；HTTPS 示例保留訪問域名對應的 Host、SNI 和證書校驗。不要用忽略證書錯誤的結果作為上線驗收依據。若實際回源使用不同的 Host、SNI 或端口，應按那組實際值測試；必要時請技術支持從 CDN 側發起檢查。源站只允許 CDN 回源地址時，本機測試可能被拒絕，應使用受控的診斷入口。
第二步：分別檢查兩段 HTTPS
訪客到 CDN、CDN 到源站是兩段連接，分別覈對：
- 訪客到 CDN：訪問域名已綁定正確證書，證書覆蓋域名，私鑰匹配且證書鏈完整。根域名與子域名分別檢查，不能只測其中一個。
- CDN 到源站：按源站實際支持的 HTTP 或 HTTPS 配置回源。HTTPS 回源還需覈對源站證書、SNI 與平臺的校驗要求。
- HTTPS 跳轉：確認 CDN 與源站的跳轉策略不會互相沖突。源站需要獲知原始訪問協議時，使用平臺實際傳遞且源站可信任的協議頭，先測試再啟用跳轉。
- 續期責任：記錄邊緣證書和源站證書的到期日、更新負責人及部署位置。控制台有證書不代表源站已同步更新。
若出現反覆跳轉，檢查每次響應的 Location，確認哪個環節把請求切回 HTTP 或另一個域名。先恢復最近修改的跳轉配置，再逐項定位。證書接入另見 SSL 接入概覽。
第三步：配置緩存和業務例外
先區分公共靜態資源與個性化響應，再設置緩存範圍和時間。
| 業務類型 | 建議處理 | 必須驗證 |
|---|---|---|
| 帶版本號的公開 CSS、JS、圖片 | 按資源更新頻率設置緩存 | 重複請求內容正確，發佈新版本能獲得新資源 |
| 登錄、用戶中心、訂單、購物車 | 明確排除公共緩存 | 兩個測試賬號互不串數據，退出登錄後狀態正確 |
| 帶 Cookie 或 Authorization 的接口 | 按鑑權與業務設計明確緩存例外 | 未登錄、已登錄、不同權限返回各自正確結果 |
| 支付通知、Webhook、機器調用 API | 排除不兼容的瀏覽器挑戰，保留必要鑑權與防護 | 用實際客戶端驗證方法、請求體、簽名和返回值 |
| WebSocket | 確認套餐、代理支持與連接超時 | 使用真實客戶端檢查握手、消息收發與重連 |
不要假定所有帶 Cookie、Authorization 或 Set-Cookie 的響應都已自動排除緩存。覈對控制台規則優先級、源站 Cache-Control 和實際命中結果；對敏感響應可在源站使用適當的 private、no-store 策略，並確認 CDN 未覆蓋這些限制。
API 和回調一般無法執行 JS 驗證或交互驗證碼。例外應限制到必要路徑、方法或可信來源，並保留業務簽名、鑑權和必要的限速。不要僅憑接口返回 200 判定成功，還要檢查返回內容是不是挑戰頁面。文件類型參考 常用緩存文件後綴。
第四步：切換 DNS
- 保存每個域名當前的 A、AAAA、CNAME 記錄、TTL 和原訪問路徑，確認有可用的回退目標。
- 從當前 SCDN 網站配置複製該域名實際分配的 CNAME，不自行拼接，也不把其他網站的目標直接套用。
- 在 DNS 服務商處按接入要求修改對應記錄。檢查同名 A、AAAA 與 CNAME 的衝突及遺留 IPv6 解析；根域名是否支持別名解析，以 DNS 服務商能力為準。
- 先切一個域名，在不同網絡與遞歸 DNS 上覆查，再逐批切換。調整 TTL 後，已有舊緩存仍需等待原 TTL 到期。
nslookup -type=CNAME www.example.com
nslookup www.example.com
若 DNS 服務商採用根域名別名或 CNAME 扁平化，查詢可能直接返回地址，應結合服務商記錄與 CDN 實際分配結果判斷。確認 DNS 後，再訪問業務頁面、檢查響應與源站日誌；僅查到 CNAME 不能證明業務已經正常。
批量接入時，分批驗證並觀察源站承載情況，給 DNS 緩存傳播留出時間。逐域名記錄檢查結果，從主要訪問地區完成驗收。批量域名接入經驗
第五步：完成上線驗收
| 驗收項 | 通過標準 |
|---|---|
| DNS 與 HTTPS | 多個網絡訪問預期路徑，證書域名、有效期和鏈均正確 |
| 首頁與靜態資源 | 頁面與資源完整，沒有錯誤跳轉、混合內容或舊版本殘留 |
| 登錄與權限 | 登錄、刷新、退出正常，不同測試賬號數據隔離 |
| 表單與 API | 使用真實方法和請求體完成操作，返回業務預期結果 |
| 回調與長連接 | 在測試環境或可控流程完成回調；WebSocket 收發和重連正常 |
| 源站與防護 | 錯誤率、耗時、CPU、帶寬和連接數無異常增長，業務請求無誤攔截 |
上線初期保留變更時間、測試域名、結果和操作人。確認一批穩定後再繼續下一批；出現異常先停止擴大變更範圍。
常見錯誤與排查順序
錯誤可能由源站、CDN 或鏈路中的其他代理返回，應使用發生時間、請求標識和兩側日誌定位實際返回方。
| 現象 | 先覈對 | 下一步 |
|---|---|---|
| DNS 無結果或仍到舊站 | DNS 記錄、域名狀態、TTL、A/AAAA 與 CNAME | 比對權威記錄和不同網絡查詢結果 |
| TLS 握手失敗、證書告警 | 當前連接的域名、證書鏈、有效期、SNI | 分別檢查邊緣與源站 TLS，修復後重新測試 |
| 301/302 循環 | Location、強制 HTTPS、源站跳轉和原始協議識別 |
恢復衝突規則，逐層驗證一次正常跳轉 |
| 401/403 | 登錄憑據、源站權限、防盜鏈與防護日誌 | 區分業務拒絕和防護攔截，再調整最小範圍規則 |
| 404 | 請求路徑、Host、虛擬主機及發佈版本 | 用相同 Host 和路徑直接驗證源站 |
| 429 | 源站或 CDN 的限速策略、重試行為 | 確認限制來自哪一側，按實際業務調整 |
| 502 | 上游連接、協議、TLS、源站異常響應 | 對比源站錯誤日誌與 CDN 請求記錄 |
| 503 | 源站服務、維護狀態、可用後端及資源使用 | 恢復健康實例或處理資源瓶頸 |
| 504 | 回源網絡、端口、Host、響應時間 | 檢查安全組、應用耗時、數據庫與連接數，再查鏈路和節點 |
持續 502/504 時，將故障時間段的源站資源、數據庫連接和回源記錄一起檢查；不要只修改超時參數。再根據排查結果調整緩存或多源站配置。502/504 排障與優化指南
回退步驟
出現關鍵流程失敗、誤緩存或持續錯誤時，先記錄故障與當前配置，再按已準備的方案恢復。
**若個性化內容被誤緩存，先立即停止相關緩存並清理已緩存內容，覈查影響範圍；必要時聯繫技術支持阻止繼續泄漏。不要等待 DNS 回退生效後再處理。**下面的常規回退步驟不能替代這項處理。
- 定位最近變更：若問題來自剛修改的緩存、防護或跳轉規則，先恢復該項原值並驗證。
- 確認回退目標可用：重新驗證原服務的域名、HTTPS、容量與防護路徑。原方案依賴其他代理時，應恢復那條完整路徑。
- 恢復 DNS：確需退出本次 CDN 接入時，恢復事先保存的解析記錄與 TTL。DNS 回退並非即時生效，過渡期間兩條路徑都可能有請求。
- 保留過渡服務：在各地緩存更新並確認請求穩定前，保留當前 CDN 網站和證書配置，不要提前刪除仍可能承接請求的服務。
- 複覈與記錄：確認各路徑已恢復、緩存問題已處理，再保存原因、修正項與再次接入條件。
原方案為直接訪問源站時，恢復直連也會恢復源站暴露與原有承載壓力。請採用接入前確認的可用路徑，必要時先聯繫技術支持協助恢復。
聯繫技術支持
- 產品、套餐、問題域名和源站協議、端口。
- 發生時間與時區、影響地區或運營商、錯誤碼及可復現的路徑。
- 本次變更內容、DNS 查詢結果、直連與經過 CDN 的測試差異。
- 脫敏後的請求標識、響應頭、源站訪問與錯誤日誌；如提供截圖，請使用當前實際界面並遮蓋敏感信息。
不要提交賬號密碼、證書私鑰、完整 Cookie、Authorization 或接口密鑰。Host/SNI 默認行為、回源 IP 清單、超時和功能開關未在當前配置中明確顯示時，請隨工單一起確認。