awesome-hacks
Docs

フレンドリーフォワーディング入門 — 仕組みと実現方法

# backend

URLを変えずに別サーバーのコンテンツを表示するフレンドリーフォワーディングとは何か、iframe方式とリバースプロキシ方式それぞれの実現方法と使い分けを説明するページ

最終更新：2026/06/23

TL;DR

  • フレンドリーフォワーディングは「ブラウザのアドレスバーのURLを変えずに別サーバーのコンテンツを返す」転送技術
  • 実現方法は iframe 方式とリバースプロキシ方式の2つが主流
  • 現代のWebでは X-Frame-Options / CSP により iframe 方式は多くのサイトでブロックされるため、リバースプロキシ方式が実用上の推奨

フレンドリーフォワーディングとは

フレンドリーフォワーディング（Friendly Forwarding）とは、ユーザーのブラウザのアドレスバーに表示されているURLを変えることなく、別のサーバー・別のURLにあるコンテンツを返す転送技術である。

ドメイン登録業者（GoDaddy、お名前.com など）が「URLフォワーディング」の選択肢のひとつとして提供することが多く、URLマスキング（URL Masking） や ステルスフォワーディング（Stealth Forwarding） とも呼ばれる。

通常のリダイレクト（301 / 302）との違い

通常の転送は HTTPリダイレクト（301 Moved Permanently / 302 Found）を使う。ブラウザは転送先のURLに再リクエストを送るため、アドレスバーのURLが変わる。

sequenceDiagram
    participant Browser as ブラウザ
    participant Origin as example.com
    participant Dest as realsite.com

    Browser->>Origin: GET / HTTP/1.1
    Origin-->>Browser: 301 Location: https://realsite.com/
    Browser->>Dest: GET / HTTP/1.1
    Dest-->>Browser: 200 OK（コンテンツ）
    Note over Browser: アドレスバー → realsite.com

フレンドリーフォワーディングでは、ブラウザは example.com にリクエストを送ったまま、realsite.com のコンテンツを受け取る。アドレスバーは example.com のまま変わらない。

sequenceDiagram
    participant Browser as ブラウザ
    participant FW as example.com（転送レイヤー）
    participant Dest as realsite.com

    Browser->>FW: GET / HTTP/1.1
    FW->>Dest: コンテンツ取得（内部）
    Dest-->>FW: 200 OK（コンテンツ）
    FW-->>Browser: 200 OK（コンテンツ）
    Note over Browser: アドレスバー → example.com のまま

なぜ使うのか

フレンドリーフォワーディングが採用される背景は一言でいえば、**「複数のサーバー・サービスにまたがるシステムを、ユーザーには1つのドメインとして見せたい」**場面が増えているからである。以下に実際によく遭遇するシチュエーションを示す。

1. 外部 SaaS をブランドドメインで提供する

最も頻繁に見られるのが、ヘルプセンター・採用ページ・ステータスページなどを外部 SaaS で動かしつつ、自社ドメインで見せるケースだ。

用途よく使われる SaaSユーザーに見せたい URL
ヘルプセンターZendesk, Intercomhelp.myapp.com
採用ページGreenhouse, Lever, Wantedlycareers.myapp.com
ステータスページAtlassian Statuspage, Incident.iostatus.myapp.com
ドキュメントNotion, GitBookdocs.myapp.com

こうしたサービスのカスタムドメイン設定ドキュメントには、ほぼ必ず「あなたのサーバー側でリバースプロキシを設定してください」という手順が掲載されている。つまり、SaaS を導入するだけでフレンドリーフォワーディングの設定が求められる場面は日常的に発生する。

ユーザーが help.myapp.com にアクセス
          ↓
Nginx がリクエストを受け取り Zendesk に横流し
          ↓
ユーザーには help.myapp.com のままコンテンツが届く

2. マーケティングサイトとアプリを同じドメインで動かす

スタートアップでよく見る構成として、Webflow や Framer で作ったマーケティングサイトと、Vercel や AWS 上の実アプリを同一ドメインに収めるケースがある。

myapp.com/         → Webflow（マーケティングサイト）
myapp.com/app/     → Vercel（Next.js アプリ本体）
myapp.com/api/     → ECS（バックエンド API）

リバースプロキシを1台挟むだけで、この3つを myapp.com という単一ドメインに束ねられる。ドメインが分散しないためブランドが統一され、SEO 上もドメインの評価が分散しないメリットがある。

3. 自社 SaaS にカスタムドメイン機能を実装する

Shopify・note・はてなブログのように、ユーザーが自分のドメインを持ち込んでコンテンツを公開できる SaaS は、このパターンをサービス基盤として実装している。

myshop.mydomain.com（ユーザーが CNAME を設定）
          ↓
Shopify のサーバーがそのドメインのリクエストを受け取り転送

SaaS を提供する側の立場になると、カスタムドメイン機能の実装でこの仕組みの理解と実装が必要になる。

4. ドメイン移行時に旧 URL を維持する

社名変更やサービスリブランドでドメインを変える場合、旧URLがブックマークや外部サイトのリンクとして広まっている。301 リダイレクトでは旧 URL が失われてしまうが、フレンドリーフォワーディングなら旧 URL のまま新サーバーのコンテンツを提供し続けられる。

どう判断するか

graph TD
    A["転送元と転送先で<br/>URLが変わってよいか？"] -->|"YES"| B["301/302 リダイレクト<br/>がシンプルで正解"]
    A -->|"NO: URL を変えたくない"| C{"転送先は自分が<br/>コントロールできるか？"}
    C -->|"NO（外部 SaaS 等）"| D["リバースプロキシ方式<br/>一択"]
    C -->|"YES（自社管理）"| E{"X-Frame-Options を<br/>外せるか？"}
    E -->|"YES"| F["iframe 方式でも可<br/>（設定は簡単だが非推奨）"]
    E -->|"NO"| D

実現方法

方法 1：iframe 方式

転送元のドメインに HTML ファイルを置き、コンテンツを iframe で埋め込む古典的な手法。ドメイン登録業者が提供する「フレンドリーフォワーディング」の多くはこの実装である。

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>example.com</title>
    <style>
      html, body { margin: 0; padding: 0; height: 100%; }
      iframe { border: none; width: 100%; height: 100vh; display: block; }
    </style>
  </head>
  <body>
    <iframe src="https://realsite.com"></iframe>
  </body>
</html>

iframe 方式の問題点

graph TD
    A["iframe でフレンドリーフォワーディング"] --> B{"転送先サイトの<br/>X-Frame-Options / CSP"}
    B -->|"DENY / SAMEORIGIN が設定されている"| C["ブラウザがブロック<br/>→ 白い画面になる"]
    B -->|"設定なし or ALLOW-FROM"| D["表示できる"]
    D --> E{"SEO の扱い"}
    E --> F["重複コンテンツとして<br/>評価が下がるリスク"]
  • X-Frame-Options / Content-Security-Policy：ほとんどの主要サイト（Google、GitHub など）は X-Frame-Options: DENY または CSP の frame-ancestors 'none' を設定しており、iframe 内に表示できない
  • SEO：検索エンジンから見ると example.com と realsite.com に同じコンテンツが存在する重複コンテンツ状態になり、SEO に悪影響を及ぼすことがある
  • cookie：転送先ドメインの cookie は転送先ドメインのものとして扱われるため、ログイン状態などが example.com 側と混在する

方法 2：リバースプロキシ方式

リバースプロキシ（Reverse Proxy）とは、クライアントからのリクエストを受け取り、バックエンドのサーバーに転送して結果を返す中継サーバーのことである。
example.com のサーバー上にリバースプロキシを立て、受け取ったリクエストをそのまま realsite.com に横流しすることでフレンドリーフォワーディングを実現する。

graph LR
    Browser["ブラウザ<br/>example.com"] -->|"HTTP リクエスト"| Proxy["リバースプロキシ<br/>Nginx / Caddy など"]
    Proxy -->|"proxy_pass"| Origin["realsite.com"]
    Origin -->|"レスポンス"| Proxy
    Proxy -->|"レスポンス"| Browser

Nginx での実装例

server {
    listen 443 ssl;
    server_name example.com;

    # SSL証明書（Let's Encrypt など）
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location / {
        proxy_pass https://realsite.com;

        # 転送先に正しい Host ヘッダーを送る
        proxy_set_header Host realsite.com;

        # クライアントの実IPを転送先に伝える
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # HTTP/1.1 を使う（Keep-Alive のため）
        proxy_http_version 1.1;
    }
}

X-Forwarded-For について

リバースプロキシを経由すると、転送先のサーバーはリクエスト元として example.com のプロキシのIPアドレスを受け取る。
クライアントの実際のIPアドレスを転送先に伝えるには X-Forwarded-For ヘッダーを付与する。

クライアント IP: 203.0.113.1
               ↓
Nginx が付与: X-Forwarded-For: 203.0.113.1
               ↓
realsite.com はこのヘッダーを読んでクライアントIPを把握する

転送先のアプリがこのヘッダーを信頼するかどうかは設定次第である（信頼するプロキシのIPを制限するのがセキュリティ上望ましい）。

Caddy での実装例

Caddyは自動 HTTPS 対応の軽量 Web サーバーで、設定が Nginx より簡潔である。

example.com {
    reverse_proxy realsite.com {
        header_up Host realsite.com
        header_up X-Real-IP {remote_host}
        header_up X-Forwarded-For {remote_host}
    }
}

方式の比較

観点iframe 方式リバースプロキシ方式
設定の容易さ簡単（HTML 1枚）サーバー設定が必要
外部サイトへの転送X-Frame-Options でほぼ不可可能
SEO重複コンテンツリスクあり適切な canonical 設定で対処可
レスポンス速度二重読み込みになる場合ありプロキシの処理分だけ微増
cookie / セッションドメインの扱いが複雑プロキシが吸収できる
SSL 証明書転送元ドメイン分のみ転送元ドメイン分のみ
推奨自社管理の転送先のみこちらを推奨

よくある落とし穴

1. redirect loop（無限リダイレクト）

リバースプロキシが realsite.com に転送し、realsite.com 側がさらに example.com にリダイレクトするループが発生することがある。
proxy_pass の Host ヘッダーと転送先のリダイレクト設定を確認する。

2. 絶対URLのリンクが転送先ドメインに変わる

転送先コンテンツ内に href="https://realsite.com/other" のような絶対URLのリンクがある場合、クリックすると realsite.com にそのまま遷移して URL がバレる。
本格的な URL マスキングを行う場合は、レスポンス本文内の URL を書き換える処理（sub_filter 等）が必要になる。

location / {
    proxy_pass https://realsite.com;
    # レスポンス中の realsite.com を example.com に書き換え
    sub_filter 'realsite.com' 'example.com';
    sub_filter_once off;
}

3. HTTPS の証明書エラー

example.com の証明書は realsite.com を対象にしていないため、転送先が正しく HTTPS で動いていても別の証明書が必要になる。Let's Encrypt などで example.com の証明書を別途取得すること。

4. canonical タグが転送先ドメインを指している

SEO 目的で URL を統一したい場合、転送先ページの <link rel="canonical"> が realsite.com を指していると、検索エンジンは realsite.com を正規ページと判断する。
example.com を正規 URL にしたいなら canonical タグも書き換えるか、転送先側で設定を変更する必要がある。

関連

おすすめBlog

Blogをもっと読む →
DocsトップへBlogも読む →