問題描述
關于CDN某個地域節點訪問異常有以下幾種場景:
- 場景一:使用ping命令訪問CDN加速域名失敗。
- 場景二:源站更改文件后,從CDN節點中獲取的仍是更改之前的文件。
- 場景三:訪問CDN加速域名后獲取的為非其站點文件內容。
問題原因
關于不同問題場景的問題原因如下:
- 場景一的原因如下:
- 本地網絡異常。
- 節點網絡異?;虮还簟?/li>
- 本地到運營商中間鏈路某路由節點故障。
- 場景二的原因如下:
- 刷新未生效。
- 讀取的是本地瀏覽器緩存。
- 被本地運營商劫持。
- 場景三的原因如下:
- 訪問的非CDN節點。
- 被某種原因劫持。
解決方案
以下是不同問題場景的解決方案:
場景一:使用ping命令訪問CDN加速域名失敗
- 排查加速域名是否在沙箱節點中,由于沙箱中的域名無法保證服務穩定性,所以會存在使用ping命令后,網絡不通的情況,此時沙箱可能正在受到攻擊。
- 檢測訪問的IP是否為CDN的節點IP。關于如何檢測,請參考診斷工具。如果訪問的節點不是CDN節點IP,請核實如下幾種情況:
- 本地是否有開啟代理軟件,因為有些代理軟件會強制更改訪問域名的解析。
- 是否綁定Host文件,將加速域名強制解析到了某個IP。
- 本地存在DNS劫持,可以在本地開啟殺毒安全軟件,并且固定本地所使用的IP為223.5.5.5、114.114.114.114的DNS或者其他安全的DNS。如果劫持情況比較嚴重,并且無法解決,則需要向網絡服務提供商投訴要求解決劫持。
- 在本地使用ping命令,連接該節點IP,以及使用站長工具在全國探測該節點IP是否存在問題,即各個地區訪問該節點均延遲均較大或者不通,本地也ping不通該節點,則該節點存在問題的可能性較大,該前提是域名確實不在沙箱中。
- 在本地的Windows主機使用tracert,或者在Linux主機使用traceroute,用來探測該IP并提供完整探測截圖,根據得到的截圖定位整個網絡鏈路的問題點。
說明:MTR信息判斷方法如下:
- 目的節點丟包率為100%,并且從目的節點往前逐個檢查,直到第一個開始丟包的節點(中間不能有丟包率為0%的路由節點),則第一個開始丟包的路由節點是問題路由的可能性較大。詳細排查步驟,請參見ping丟包或不通時鏈路測試說明。
- 請阿里云技術支持進行排查,在此期間可更改本地DNS為其他DNS(例如223.5.5.5或者114.114.114.114),并刷新本地的DNS緩存,使其調度到其他正常的節點。
場景二:從CDN節點中獲取的仍是更改之前的文件
- 檢測訪問的IP是否為CDN的節點IP。
- 根據CDN的配置,綁定CDN節點和源站。綁定源站測試時,請注意如下幾點:
- CDN的回源Host配置中,使用curl命令測試源站的命令如下。如果綁定Host文件,那么應該將CDN加速域名綁定Host到源站域名所解析出來的IP地址。
curl -H "Host:[$Domain_Name]" "[$Source_Station]"
說明:
- [$Domain_Name]為CDN加速域名。
- [$Source_Station]為源站域名。
- 不同的回源端口得到的訪問結果也可能不一樣,分別測試得到Response Headers相關信息,判斷訪問的文件是否一致,主要判斷以下幾個方面:
說明:如果以下三點存在任何一項不一致的情況,那么可認為源站和節點上文件的確不一致。如果都存在的情況下,則第三點最具備判斷依據。
- Content-Length大小是否一致。
- Last-Modified的修改時間是否一致。
- ETag和Content-MD5是否一致。
- CDN的回源Host配置中,使用curl命令測試源站的命令如下。如果綁定Host文件,那么應該將CDN加速域名綁定Host到源站域名所解析出來的IP地址。
- 如果上述步驟確認后都無問題,最終在節點上獲取的文件仍和源站文件不一致,建議刷新URL,等待約10分鐘后再進行測試,如果多次刷新之后問題仍未解決,請提交工單。
說明:刷新生效時間約為5~10分鐘。
場景三:訪問CDN加速域名后獲取非其站點文件內容
- 檢測訪問的IP是否為CDN的節點IP。
- 排查CDN節點本身是否緩存了非用戶站點上的文件。
- 排查客戶端到CDN節點這段鏈路,具體方法如下:
- 打開Chrome瀏覽器的開發者工具,切換到Network,并在地址欄輸入訪問的URL。
- 單擊訪問的URL,查看實際的訪問情況。查看報錯request URl、remote ip、requestUrl,主要查看訪問形式是否為
http://192.168.0.1/cache/CDN
?;蛘卟榭磖emote IP是否為CDN節點IP,如下圖這種則是劫持。此時,需要聯系其本地運營商投訴處理,解除劫持。
適用于
- CDN