加了防盜鏈，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）批量替換成新的儲存服務連結前綴

#唉，想想都很麻煩。 。 。所以條件允許的話，還是建議大家把圖片存到自己的伺服器（物件儲存服務），更安全放心一些。

教學推薦：《Git教學》