ブログに戻る
テクノロジー

画像を他サイトに貼るとリンク切れ？403 とホットリンク防止の完全トラブルシューティング（2026 更新）

公開日20 min read
共有

画像のリンクをブログに貼り、手元のプレビューでは問題なし。公開すると、他人に見えるのは割れた画像アイコン。あるいはもっと悪く、画像の位置が一面の空白で何も出ない。

この落とし穴は一度ならず踏みました。本番で一度やらかしたのは友人の掲示板の画像を移したとき。ローカルは全緑、公開後にトップの3分の1のサムネイルが全部割れた。当時はキャッシュのクリア漏れかと思い、3日デバッグして、やっと自分のせいではないと気づく。画像の元サイトがホットリンク防止（hotlink protection）を有効にしていて、自ドメイン以外からのリクエストを一律ブロックしていたのです。

アーキテクチャの視点で見ると、「画像が他サイトで表示されない」は、実は3つの別々の失敗が混ざって語られている。正しく直す第一歩は、自分がどれに当たっているかを切り分けることです。

先に切り分ける：403・リンク切れ・200 空白は別物

画像が消えるとみな「リンク切れ」と一括りにして手当たり次第に試す。だがこの3症状は根本原因が大きく違い、対応する切り分け経路も別です。

症状 HTTP ステータス 最有力の根本原因 切り分け方向
割れた画像アイコン 403 / 404 ホットリンク防止でブロック、または URL 自体が間違い Referer と URL の正しさを確認
割れた画像アイコン 200 だが画像でない 受け取ったのは HTML エラーページで画像ファイルではない Content-Type を確認
一面の空白（割れアイコンなし） 200 CSS で覆われた、または CSP で読み込みブロック DevTools Console と CSP を確認
アイコンが回転して消える タイムアウト / CORS クロスドメイン方針かサーバータイムアウト Network のリクエスト詳細を確認

先にステータスコード、次に Content-Type、最後に画面。この順を逆にすると堂々巡りになります。

仕組み：Referer とホットリンク防止はどう動くか

なぜ他サイトの画像がブロックされるのか。まずブラウザが画像を読むとき裏で何をしているかを知る必要があります。

ページ A が <img src="https://B.com/photo.jpg"> で B サイトの画像を読むとき、ブラウザが出すリクエストには Referer ヘッダーが付く（そう、この単語は歴史的に綴りを間違えていて r が1つ足りない。間違ったまま今日まで来ている）。このヘッダーが B サイトに「この画像は A サイトのページから要求された」と伝える。

仕組みはこう。B サイトのサーバーや CDN はリクエストを受けると、Referer のドメインをホワイトリストと照合する。照合ロジックはおおよそ——

1. Referer が空（直接画像を開く、ブックマーク）→ 設定次第で許可 or ブロック
2. Referer のドメインがホワイトリストにある → 許可
3. Referer のドメインがホワイトリストにない → 403 Forbidden を返す

これがホットリンク防止です。目的は単純で、他人に自分の帯域をタダ食いされたくない。あなたが自サイトに B サイトの画像を埋めると、他人があなたのページを見るたびトラフィックの請求は B サイト側に付く。B サイトは当然おもしろくない。

ここに多くの人が知らない細部が。現代ブラウザのデフォルトの Referrer-Policy は strict-origin-when-cross-origin。クロスドメイン時は「オリジンのドメイン」だけ（例：https://a.com/）を送り、フルパスは送らない。だからホットリンク防止はあなたのドメイン名を得られ、ホワイトリスト照合にもブロックにも十分。これがホットリンク防止が hotlink を止められる理由です。

なぜ他サイトでリンク切れになるか：原因切り分けツリー

仕組みを広げると、リンク切れの根本原因は1本のツリーに収束します。上から辿ってください。

分岐1：ステータスコードは 403 か?

そうなら9割はホットリンク防止。B サイトがあなたの Referer をホワイトリスト外と見て拒否した。この場合 B サイトの設定は変えられない。唯一の解は B サイトの画像を hotlink するのをやめること（後述）。

分岐2：ステータスは 200 だが画面はリンク切れ?

その「画像」の生の中身を見てください。受け取ったのは1ページの HTML かもしれない。403 を返さず「無断転載禁止」の案内ページを 200 で返すサイトがある。ブラウザは HTML を画像として解析しようとし、当然割れる。Content-Type を見れば露見する。正常な画像は image/jpeg、image/png。エラーページは text/html。

分岐3：貼ったのは「ページのリンク」で「画像の直リンク」ではない?

初心者が最も踏む雷。https://imgur.com/aBcDeFg は ページ、https://i.imgur.com/aBcDeFg.jpg が 画像ファイルそのもの。前者を <img src> で読むと、返るのは HTML 一枚で画像ではない。i. と拡張子の差だけで、結果は天と地です。

分岐4：Referrer-Policy が自分の首を絞めた?

やや見えにくいパターン。ページに Referrer-Policy: no-referrer を設定していると、ブラウザは画像読み込み時に Referer を一切送らない。ホットリンク防止の設定が「空 Referer は一律ブロック」だと、自分のプライバシー設定で締め出される。実測では、プライバシーに敏感で meta referrer を殺しているサイトでよく起きます。

実地診断：DevTools と curl の2手で特定

理論の後は実地。私は固定で2ツールを使い、5分以内に9割のリンク切れを特定します。

手1：DevTools の Network パネル

ブラウザの開発者ツール（F12）を開き Network へ。ページを再読み込みし、フィルタに画像ファイル名を打つ。そのリクエストを開いて3つを見る。

  • Status：403、404、それとも 200?
  • Response Headers の Content-Type：image/* か text/html か?
  • Request Headers の Referer：実際に送られたのは何か。空か、自分のドメインか?

3つを見れば根本原因はだいたい浮かびます。

手2：curl で Referer を手動制御

DevTools は現象を見られるが「本当にホットリンク防止か」を検証するには curl が最も潔い。任意の Referer を手で入れ、サーバーの反応の変化を見ます。

# Referer を全く付けない（画像を直接開くのを模擬）
curl -I "https://example.com/photo.jpg"

# 「元サイト自身から来た」ふりの Referer を付ける
curl -I -H "Referer: https://example.com/" "https://example.com/photo.jpg"

# 「あなたの外部サイトから来た」Referer を付ける
curl -I -H "Referer: https://your-blog.com/" "https://example.com/photo.jpg"

読み方は直感的。1本目と3本目が 403、2本目が 200 なら——おめでとう、ホットリンク防止で確定。サーバーは元サイト自身の Referer しか認めず、他は一律ブロック。3本とも 200 なら、リンク切れはホットリンク防止と無関係。URL か CSP を疑い直す。

私の実測の癖は3本まとめて走らせること。1本ずつより対照が段違いに分かりやすい。これが「ブラウザで当てずっぽうにクリックする」より curl が効率的な理由です。

よくある画像ホスティング / CDN のホットリンク挙動

サービスごとにデフォルトの気性はかなり違う。以下はこの数年で画像を移してきた観察。実設定は各社いつでも変え得るが、大方向はこうです。

サービス種別 デフォルトでホットリンク防止 空 Referer の挙動 外部直リンク向き?
自前 Nginx / Apache 設定次第 通常は許可 設定次第
企業級 CDN（ホワイトリスト設定可） オンオフ可 許可 or ブロックを設定可 正しく設定すれば可
一部の無料画像ホスティング よくオン よくブロック よくブロックされる
SNS の画像ドメイン ほぼ全部オン ほぼブロック 不可、諦めて
共有主目的の画像ホスティング 通常オフ 許可 可、それが存在意義

肝は最後の2行。SNS（各種ソーシャルの CDN ドメイン）の画像は、コピーした URL がほぼ100%外部リンクできない。ビジネスモデルがあなたをサイト内に閉じ込めることだからです。日本だと Pixiv も同様で、作品画像の直リンクにはホットリンク防止がかかり、外部の <img> からは基本ブロックされる。それらの画像を別所に貼ろうとしても行き止まりです。

一方「共有」を主目的にした画像ホスティングは、ホットリンク防止がデフォルトでオフ。存在意義があなたの画像を外部から安定して読ませることだから。この2種は絶対に混同しない。

Referrer-Policy の罠：ブラウザまで自分を裏切る

先に触れた見えにくいパターンをここで展開します。最もデバッグで人を疑心暗鬼にさせるから。

Referrer-Policy はページ（リクエストを出す側）が設定できるヘッダー。ブラウザがどれだけ Referer 情報を送るかを決めます。値は数種。

  • no-referrer：全く送らない。
  • origin：オリジンのドメインだけ送る。
  • strict-origin-when-cross-origin：クロスドメインはドメインだけ、HTTP へ降格すると送らない（現代のデフォルト）。
  • unsafe-url：フルパスまで送る（非推奨、プライバシーが漏れる）。

矛盾はここ。ホットリンク防止は Referer で元を判定したいが、プライバシー方針は Referer を減らすか送らないよう促す。あるサイトがプライバシーを理由に no-referrer を設定すると、ホットリンク防止があり「空 Referer は一律ブロック」の画像を読みに行くと、全部割れる。

私が本番でやらかした一件がこれ。プライバシー重視のサイトが全体に no-referrer を掛け、結果すべての外部リンク画像が割れた。当時は画像ホスティングが落ちたと思い、半日調べて、自分の meta 設定が Referer を殺していたと判明。「プライバシー強化」がまさか自分を害するとは思わないので、この雷は想像しにくい。

正しい対処：他人の画像を hotlink しない

切り分けを突き詰めると、残酷な事実に行き着く。画像が自分でホスティングしたものでない限り、どんな「他サイトの画像」も、自分に制御できないタイミングで消え得る。相手がホットリンク防止を変える、URL を換える、ファイルを消す、サイトごと閉じる。そのたびにあなたのページも一緒に割れる。

本当に安定する方法は2本だけ。

第一、画像を自分が制御できる場所に再ホスティングする。 他人の URL を直接埋めない。画像をダウンロードし、自分のスペースか外部リンクを許可する画像ホスティングにアップし、その安定 URL に差し替える。アーキテクチャで言えば、この一手の本質はページの可用性を、他人のサーバーから自分の手に取り戻すこと。元が自分の制御外なら、相手の一度のホットリンク防止変更、URL 構造改修、サイト閉鎖が、そのままページのリンク切れになり、しかも予兆すら受け取れず、読者の報告で初めて炎上に気づく。すでに他人ドメインに散らばった旧リンクをまとめて移すなら、別に 画像リンク一括置換の完全 SOP を書いたので、スクリプトで全サイトの旧 URL を洗い出して一括置換すると手作業より段違いに楽です。制御できる元こそ、安定した元。

第二、ホットリンク防止がデフォルトでオフの画像ホスティングを選ぶ。 多くの無料画像ホスティングは帯域節約のため外部リンクをブロックし、掲示板やブログに貼ると割れる。外部リンクしたいなら、直リンクを明確に許可するサービスを選ぶ。

これは私たちが lpic.cc を作るときの原則の1つでもあります。アップ後に返すのは安定した画像直リンク URL。外部サイトをデフォルトでブロックせず、掲示板・ブログ・Discord に貼っても正常に表示され、わけもなく 403 にならない。私的な画像はパスワード保護で誰が見るかを制御できる。試すなら1枚無料アップロードし、リンクを別ページに貼れば安定するか分かります。

正直に制限も。現状の無料プランの画像は30日保存で永久保管ではなく、サービスは広告収益で支えられている。長期保管や商用の大量画像庫なら、有料の専門プランや、バックアップを備えた自前ストレージを評価すべき。道具は場面に合わせて選んで初めて意味がある。これは雷を踏んで学びました。

よくある質問 FAQ

Q：同じ画像リンクなのに、自分は開けて、他サイトに貼ると割れるのはなぜ?

「直接画像を開く」ときは Referer が空か許可された元から来るのでホットリンク防止が許可する。他サイトに貼ると Referer がその外部ドメインになり、ホワイトリスト外でブロックされて 403 になる。同じ URL でも Referer が違えば結果は全く別です。

Q：403 とリンク切れは同じこと?

違う。403 はサーバーの明確な拒否（ステータス 403）。リンク切れはブラウザが「画像を描けない」画面表現。403 はリンク切れを起こすが、リンク切れは URL 間違い、Content-Type 間違い、CSP による読み込みブロックなど他の原因でも起きる。先にステータスコードを見てどれか判断を。

Q：ページを Referrer-Policy: no-referrer にすればホットリンク防止を回避できる?

できるときもあれば、逆にもっと悲惨なときもある。相手が「空 Referer は許可」なら Referer を送らないことで通る。相手が「空 Referer は一律ブロック」なら逆に全滅する。この手は当てにならず、正解として使わない。

Q：プログラム（Python / Node）で画像を取っても 403、どうすれば?

ブラウザと同理で、プログラムが正しい Referer を付けていない。curl で相手がどの Referer を認めるか先にテストし、HTTP リクエストに同じヘッダーを補う。ただし他人のホットリンク防止を回避して画像を取る行為は相手の利用規約に違反し得るので、自己判断で。

Q：ある画像ホスティングが外部リンク可能かを素早く判断するには?

テスト画像を1枚アップし、その直リンク URL に curl -I -H "Referer: https://google.com/" を走らせる。200 なら外部リンク許可、403 ならホットリンク防止あり、他サイト貼りには使わない。30秒で検証完了です。

Q：日本の掲示板（5ch など）に画像を貼るとき、どの元だと安全?

外部リンクを明示的に許可する画像ホスティングの直リンクが安全。5ch の画像貼りは、貼った先ではなく元サーバーのホットリンク方針で表示可否が決まる。Pixiv や X の画像 URL をそのまま貼ると、ホットリンク防止や風控でしばしば割れる。外部リンク前提の画像ホスティングにアップし直してから貼るのが確実です。

References

#ホットリンク防止#hotlink protection#403 Forbidden#Referer#Referrer-Policy#CDN#画像直リンク
H

著者

Harvey Zhang

共同創業者・CTO

バックエンドエンジニア出身。システムアーキテクチャの観点から画像ホスティングサービスの技術実装を深く解説します。