加了防盜鏈，Gitee 圖床掛了！
大家好，我是魚皮，這兩天又發生了一件挺意外的事情：Gitee 的圖床廢了！
圖床：指儲存圖片的伺服器，便於在網上展示圖片
昨天晚上，星球裡不止一位小夥伴發貼文表示自己網站、文章中的圖片竟然全部變成了 Gitee 的圖示？！
我當時還不瞭解真相，心想 Gitee 這麼大的程式碼開源平臺也能掛？就問小夥伴怎麼回事：
我想，如果是官方的問題，那肯定很多用 Gitee 來做圖床的專案檔案都會受到影響。於是我就去 GitHub 上隨便搜了幾個專案，果不其然，很多專案檔案裡的圖示都變成了 Gitee。
千萬別小看這個事情的影響！一方面是鬧了不少笑話，比如下圖這個專案的贊助商，都變成了 Gitee：
還有一些作者的引流、打賞二維條碼清一色都變成了 Gitee 圖示，這就直接影響到作者的收入了！（一天了，作者還沒發現，請大家廣而告之~）
還有同學的部落格變成了這樣。。。
於是我先去網上簡單調研了一下，有不少小夥伴都遇到了這個問題，那估計就是官方的鍋了。
然後我進入 Gitee，找到自己之前搭建的圖床倉庫（專門用來存放圖片的程式碼倉庫），隨便找到一張圖片，先進入圖片檢視頁（路徑包含 blob），然後點選原始資料檢視原圖：
通過跳轉的方式是能夠順利開啟圖片的（原圖頁面的地址不包含 blob）：
然後我直接複製圖片的地址，重新整理頁面，結果就看不到圖片了。按 F12 來監聽網路請求，發現圖片請求並沒有得到正確的響應，反而得到了一個 favicon.ico：
猜一猜就知道了，這個 ico 檔案果然就是 Gitee 的圖示！
那為什麼從 Gitee 自己的頁面跳轉到真實圖片地址就能顯示出圖片，直接存取地址就會被攔截呢？
顯然是 Gitee 給圖片新增了 防盜鏈 ，一般情況下，伺服器端會從使用者端的請求頭中讀取 Referer，通過判斷 referer 頭是否在白名單中，來決定正常響應圖片還是攔截。
為了驗證這點，再做個實驗。先用 Firefox 瀏覽器直接開啟 Gitee 圖片的真實地址，果然無法顯示：
然後我們在 F12 開發者工具中找到剛剛的圖片請求，點選編輯並重發：
然後給之前的請求補充上一個 Referer，表示從哪個頁面跳轉到了目標頁面：
果然，圖片就成功響應了：
看來，Gitee 這波真的是加了防盜鏈，事先沒有一點兒通知（直到我發文前，也沒有通知）。大家紛紛表示傻眼了：
那既然事情已經發生了，無論 Gitee 官方到底是臨時還是永久新增了防盜鏈，我都不建議大家繼續使用 Gitee 作為圖床（本身它還有 1 M 圖片大小的限制）。而是應該使用七牛雲、或者騰訊 / 阿里等雲服務廠商提供的穩定的物件儲存服務。
對於目前已經受 Gitee 影響的小夥伴，可以做以下幾件事：
找到新的物件儲存服務
把 Gitee 倉庫的程式碼打包下載並完整上傳到新的物件儲存服務中（保證路徑一致）
使用文字編輯器將圖片的連結字首（gitee.com/xxx）批次替換成新的儲存服務連結字首
唉，想想都麻煩。。。所以條件允許的話，還是建議大家把圖片存到自己的伺服器（物件儲存服務），更安全放心一些。
教學推薦：《》