突發!Gitee 圖床,廢了!

程式設計師魚皮發表於2022-03-26

大家好,我是魚皮,這兩天又發生了一件挺意外的事情: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 圖片大小的限制)。而是應該使用七牛雲、或者騰訊 / 阿里等雲服務廠商提供的穩定的物件儲存服務。

很早之前寫過一篇圖床搭建教程:《使用 Typora + PicGo 提升百倍寫作效率》 ,大家感興趣可以閱讀一下。

對於目前已經受 Gitee 影響的小夥伴,可以做以下幾件事:

  1. 找到新的物件儲存服務

  2. 把 Gitee 倉庫的程式碼打包下載並完整上傳到新的物件儲存服務中(保證路徑一致)

  3. 使用文字編輯器將圖片的連結字首(gitee.com/xxx)批量替換成新的儲存服務連結字首

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

我也給自己 程式設計知識星球 內的小夥伴建設了一個 免費高速靈活 的圖床(使用騰訊雲 COS),幫助大家省去自己搭建的時間和金錢成本。歡迎大家的加入~

相關文章