バースト！Giteeマップベッドは役に立たない

みなさん、こんにちは。私はユピです。この2日間で、非常に予期しないことが起こりました。Giteeのマップベッドは役に立たないのです。

ピクチャーベッド：インターネット上で写真を表示するのに便利な、写真を保存するサーバーを指します

昨夜、地球上の複数の友人が、彼のWebサイトと記事のすべての写真がGiteeアイコンに変わったと投稿しましたか？！

当時、私は真実を知りませんでした。Giteeと同じくらい大きなオープンソースプラットフォームがハングアップする可能性があると思いましたか？何が起こったのか友達に聞いてください。

それが公式の問題であれば、Giteeをマップベッドとして使用する多くのプロジェクトドキュメントが影響を受けると思います。そこで、GitHubにアクセスしていくつかのプロジェクトを検索しました。確かに、多くのプロジェクトドキュメントのアイコンはGiteeになっています。

これの影響を過小評価しないでください！ジョークがたくさんあります。たとえば、以下のプロジェクトのスポンサーはGiteeになりました。

QRコードがすべてGiteeアイコンに変換され、著者の収入に直接影響する著者もいます。（1日経ちましたが、作者はまだ見つけていませんので、広めてください〜）

同級生のブログもこんな感じになります。。。

そこで、簡単な調査のためにインターネットに行きましたが、多くの友人がこの問題に遭遇したので、それが公式のポットであると推定されます。

次に、Giteeに入り、以前に作成した画像ベッドウェアハウス（画像の保存専用のコードウェアハウス）を見つけ、ランダムに画像を見つけ、最初に画像表示ページ（パスにblobが含まれています）に入り、元のデータをクリックして元の画像を表示する：

ジャンプすることで画像をスムーズに開くことができます（元の画像ページのアドレスにはblobが含まれていません）。

次に、画像のアドレスを直接コピーしてページを更新すると、画像が表示されなくなりました。F12キーを押してネットワーク要求を監視し、画像要求が正しい応答を取得せず、代わりにfavicon.icoを取得したことを確認します。

何だと思いますか、このicoファイルは本当にGiteeのアイコンです！

では、なぜGitee自身のページから実際の画像アドレスにジャンプして画像を表示すると、アドレスへの直接アクセスがブロックされるのでしょうか。

どうやら、Giteeは画像にアンチ。通常、サーバーはクライアントのリクエストヘッダーからリファラーを読み取り、リファラーヘッダーがホワイトリストにあるかどうかを判断して、画像に通常応答するか傍受するかを決定します。。

为了验证这点，再做个实验。先用 Firefox 浏览器直接打开 Gitee 图片的真实地址，果然无法显示：

然后我们在 F12 开发者工具中找到刚刚的图片请求，点击编辑并重发：

然后给之前的请求补充上一个 Referer，表示从哪个页面跳转到了目标页面：

果然，图片就成功响应了：

看来，Gitee 这波真的是加了防盗链，事先没有一点儿通知（直到我发文前，也没有通知）。大家纷纷表示傻眼了：

那既然事情已经发生了，无论 Gitee 官方到底是临时还是永久添加了防盗链，我都不建议大家继续使用 Gitee 作为图床（本身它还有 1 M 图片大小的限制）。而是应该使用七牛云、或者腾讯 / 阿里等云服务厂商提供的稳定的对象存储服务。

很早之前写过一篇图床搭建教程：《使用 Typora + PicGo 提升百倍写作效率》，大家感兴趣可以阅读一下。

对于目前已经受 Gitee 影响的小伙伴，可以做以下几件事：

唉，想想都麻烦。。。所以条件允许的话，还是建议大家把图片存到自己的服务器（对象存储服务），更安全放心一些。