問題現象

請求CDN加速資源時，CDN節點響應403狀態碼，無法訪問資源。

可能原因及解決方案

場景一：加速域名在CDN平臺上未配置

若域名未在CDN加速平臺進行配置，該域名請求訪問到CDN節點時，CDN會直接響應403。具體報錯如下：

解決方案：針對加速域名未在CDN平臺配置的情況，可以將需要加速的域名在CDN平臺上配置，配置完成后，進行對應的CNAME ，再重新請求對應的資源。

場景二：源站響應403問題

當用戶端對該資源發起請求，CDN轉發回源，源站如果響應403狀態碼給CDN，CDN會將403響應給用戶端。具體報錯如下：

解決方案：針對源站響應的403，需要源站排查對應原因，源站修改對應響應后，用戶端再重新發起請求。

場景三：鑒權問題

域名在CDN平臺配置了鑒權規則，如果請求的URL鑒權計算方式錯誤、鑒權過期、沒有攜帶鑒權參數都可能導致響應403。具體報錯如下：

解決方案：針對鑒權引起的403問題，如果是沒有攜帶鑒權參數，請重新發起帶有鑒權規則的URL請求，如果業務不需要鑒權功能，可以登錄CDN控制臺，關閉對應的鑒權功能，生效后再重新請求對應的資源；如果是鑒權過期和鑒權的計算方式錯誤，需要重新根據配置的鑒權規則生成新的URL，再請求重新生成的URL資源。

場景四：URL違規問題

當CDN對某資源下發封禁任務后，用戶再訪問該資源，CDN會響應403。以及當客戶開啟CDN內容審核增值服務，在平臺發現違規資源時，CDN會自動下發封禁任務，此時如果客戶對該域名配置啟用了URL封禁的策略，此時也會響應403。這兩類均歸結為URL違規問題。當因為URL違規而進行封禁出現403時，Deny-Reason響應頭可能會出現如下幾種：deny by block_catchkey_ignore_url、deny by block_full_url、deny by block_ignore_url、deny by block_catchkey_plus_url。具體報錯示例如下：

解決方案：針對URL違規引起的403，對違規的內容進行整改，確保整改后內容為合法。

場景五：防盜鏈問題

防盜鏈包含時間戳防盜鏈、Referer防盜鏈等，防盜鏈問題引起的403，通常表現為請求的方式不符合域名配置的防盜鏈規則，引起403錯誤。具體報錯如下：

解決方案：針對防盜鏈引起的403問題，詳情請見：防盜鏈異常導致訪問資源返回403問題排查。

場景六：IP黑白名單問題

在CDN平臺上配置了IP黑白名單，導致出現403。具體報錯如下：

解決方案：如果IP在配置的黑名單里或者不在可訪問的白名單內，可以在CDN控制臺進行配置調整，配置生效后，再重新發起請求。

場景七：端口不匹配問題

域名配置的端口與訪問請求到的端口不匹配時，會導致出現403。具體報錯如下：

解決方案：如果是訪問時指定了錯誤的端口，請調整為正確端口后，再發起請求。如果是域名配置的端口不準確，請在CDN控制臺進行端口配置調整，配置生效后，再重新發起請求。