概述
CDN訪問出現403通常情況下可能是由以下幾種情況導致的，我們可以打開瀏覽器開發者模式，切換到Netwrok標籤頁以後重新請求異常的URL，復現403的問題，然後在Headers下查看CDN返回的Response Header，通過這個信息我們可以判斷這個403錯誤是什麼原因引起的。本文會對這些情況做具體講解，以下是本文概圖。
一.加速域名未添加到CDN
用戶在CDN上添加了主域名test.com，對應的CNAME是test.com.alikunlun.com，然後用戶的一些其他的二級域名比如a.test.com、b.test.com等域名並沒有添加到CDN上，但是卻直接將這些二級域名解析到test.com.alikunlun.com，這種情況會導致CDN響應403，具體報錯如下。
注意：主域名的CNAME不能被二級域名使用，如果需要加速這些二級域名，需要把二級域名單獨都添加到CDN上，並解析到對應的CNAME地址上。或者考慮使用泛域名的方式，泛域名的CNAME是可以被二級域名使用的。
X-Tengine-Bf-Error: non-existent domain
二.CDN鑑權問題
CDN鑑權問題通常表現在沒有帶鑑權參數、鑑權過期、鑑權計算錯誤，需要根據URL鑑權的文檔瞭解鑑權的原理然後去進一步排查和解決。
1. CDN開啟了鑑權，但是實際的訪問URL裡沒有帶鑑權參數，導致報錯如下
X-Tengine-Error:denied by req auth: no url arg auth_key 
2. 鑑權參數過期
CDN開了鑑權，並且URL帶了鑑權參數，但是鑑權參數過期
X-Tengine-Error: denied by req auth: expired timestamp
3. 鑑權參數的md5計算不正確
X-Tengine-Error: denied by req auth: invalid md5hash
解決方案：
- 如果不需要CDN的鑑權功能，可以在CDN控制檯關閉鑑權。
- 如果鑑權過期，請重新生成鑑權URL。
- 如果鑑權的md5計算不正確，建議先用CDN控制檯的地址生成器生成URL來對比自己的鑑權代碼，也可以參考官方幫助文檔提供的鑑權示例代碼。
三.防盜鏈問題
開啟了防盜鏈功能，但是實際Request Headers請求頭裡的Referer頭不符合防盜鏈規則導致失敗，因防盜鏈問題導致的403，在CDN的Response headers裡的X-Tengine-Error會返回denied by Referer ACL。防盜鏈配置請參考配置文檔。
X-Tengine-Error: denied by Referer ACL
Referer防盜鏈類型如下：
- 黑名單:黑名單內的域名均無法訪問當前的資源。
- 白名單:只有白名單內的域名能訪問當前資源，白名單以外的域名均無法訪問當前的資源。
黑名單和白名單互斥，同一時間只支持其中一種方式生效。
1.請求頭裡沒有帶referer頭，也就是說該HTTP請求是一次空referer的請求的。而CDN控制檯又設置了不允許空referer，因此該請求會被403，參考如下案例。
解決方案：如果希望允許空referer的請求，可以登錄CDN控制檯，單擊對應的加速域名 管理，選擇 訪問控制 > Refer防盜鏈 > 修改配置，，勾選“允許通過瀏覽器地址欄直接訪問資源URL”。
注：如將防盜鏈設置不允許為空Referer訪問，這樣操作，有被盜鏈的風險。
2.設置了防盜鏈白名單，但是實際請求時，請求頭裡的referer頭不在白名單裡。例如如下案例，設置的白名單是www.test.com， 但是實際訪問的時候，請求頭裡的referer頭是dc.xxx.cn，未在白名單裡，因此403。
四.IP黑白名單問題
在CDN控制檯配置了IP黑白名單，實際訪問的IP不符合配置規則，導致出現403。
1.配置了IP白名單，實際訪問的客戶端IP不在IP白名單裡，導致403，具體報錯如下
X-Tengine-Error: denied by IP ACL = not in whitelist
2.配置了IP黑名單，實際訪問的客戶端IP在IP黑名單裡，導致403，具體報錯如下
X-Tengine-Error: denied by IP ACL = blacklist
常見問題
- 問：為什麼配置了IP黑名單，還是可以正常訪問，響應200，而不是403？
答：這種情況一般都是客戶端真實出口IP跟IP黑名單裡配置的IP不一致導致的。建議獲取客戶端真實出口IP，可以通過IP工具查詢；也可以通過下載CDN的日誌，從CDN的日誌去查找這條請求，CDN的日誌裡記錄了客戶端IP。 - 問：發現惡意請求的情況，把惡意請求的客戶端IP配置到黑名單了，為什麼還是不斷有請求CDN？
答：CDN作為一個服務端，無法控制客戶端不請求CDN，CDN能做的是當惡意請求到CDN的時候，CDN根據配置的安全規則拒絕不合法的請求，以403的形式拒絕訪問。
五.UA黑白名單問題
配置了UA黑白名單，User-Agent名單類型如下：
- 黑名單：黑名單內的User-Agent字段均無法訪問當前資源。
- 白名單：只有白名單內的User-Agent字段能訪問當前資源，白名單以外的User-Agent字段均無法訪問當前資源。
黑名單和白名單互斥，同一時間只支持其中一種方式生效。
1. 配置了UA黑名單，客戶端UA命中了黑名單規則，報錯如下
X-Tengine-Error: black ua
2. 配置了UA白名單，客戶端UA不在UA白名單列表裡，報錯如下
X-Tengine-Error: not in white ua
六.URL違規被屏蔽
403的URL涉及違法不良信息，違反了相關服務協議和《互聯網信息服務管理辦法》第十五條規定，這種情況下違法URL會被CDN做屏蔽訪問處理。通常這種情況會收到郵件或短信通知，請注意確保CDN加速的內容是合法的內容。報錯如下
x-swift-error:request hit url black list
七.源站響應403
源站響應了403給CDN，CDN再把403響應給客戶端。源站響應的403會報錯如下
X-Swift-Error: orig response 4XX error
-
源站是用戶服務器
可以綁定Host到源站訪問測試是否一樣存在403的情況，如果源站就有403的情況，需要先解決源站的403問題。另外還有一點需要注意，CDN的回源Host配置錯誤也可能導致403錯誤。回源HOST跟源站的區別就是，源站決定了回源時請求到的具體IP地址，而回源HOST決定了回源請求訪問到該IP地址上的具體站點。 -
源站是阿里雲OSS
如果源Bucket的訪問權限是私有權限，但是訪問URL裡沒有帶上OSS的私有簽名參數（Signature、Expires、OSSAccessKeyId），就會導致CDN回源請求OSS的時候通不過OSS的鑑權導致403，報錯如下You have no right to access this object because of bucket acl 。
這種情況建議開啟CDN的阿里雲OSS私有Bucket回源授權功能。
如果出現如下錯誤，說明是OSS防盜鏈鑑權返回的403，則需要檢查OSS的防盜鏈設置。
You are denied by bucket referer policy
