「Blocked request. This host is not allowed」: Vite、Rails、Django、Angular、Next.js の Host-Header 許可リスト チートシート

トンネルを開始して公開URLをブラウザに貼り付けると、アプリの代わりに平凡なエラーが返ってきます。Vite プロジェクトでは Blocked request. This host ("your-name.tunnel.example.com") is not allowed. と表示されます。Rails では 403 Forbidden、Django では 400 Bad Request、Angular の開発サーバーでは再び Vite のメッセージ、Next.js ではページが読み込まれることがありますが、/_next/* 配下の開発専用リクエストはブロックされます。

これらはすべてトンネルのバグではありません。あなたの開発サーバーが、今まで聞いたことのないホスト名へのリクエストを受け取り、応答を拒否しただけです。本ガイドはフレームワーク別のチートシートです。設定の正確な値、受け付ける値、デフォルト、そして安全に構成する方法を詳述します。また、安定したトンネルのサブドメイン があると、繰り返される煩わしさを一度きりの設定行へと変えられる理由も説明します。

なぜ dev サーバは Host ヘッダをチェックするのか

すべての HTTP リクエストには、ブラウザが通信していると考えるサイトを示す Host ヘッダが含まれます。歴史的に、多くの開発サーバーはこれを無視してきました。DNS リバインディングの問題が生じ、攻撃者がコントロールするドメインからのページを読み込んだ場合、攻撃者の DNS が 127.0.0.1 に応答を返し、ブラウザはローカルサーバを攻撃者の起源の一部として扱います。その結果、攻撃者のページは開発サーバーが返す内容を読み取れてしまいます。

Host ヘッダを許可リストと照合することで、攻撃者のドメインがリストにない場合は受信を拒否します。Rails はこれを DNS リバインディング対策のガードとして説明します。Vite のドキュメントは、チェックを広く開くと DNS リバインディングを通じてソースコードをダウンロードできると警告します。

正当なトンネルのホスト名も、リストに載るまでは“未知”と見なされるコストがあります。

トンネルには Vite 固有の細部があり、 dev サーバー自体が HTTPS を提供している場合にはホストのチェックをスキップします。多くのトンネルは TLS をエッジで終了させ、プレーン HTTP をマシンに転送しますが、その設定でもチェックは適用されます。

迅速診断: どのレイヤーが拒否しているのか？

Framework	設定	表示される内容
Vite	server.allowedHosts	403 with Blocked request. This host (...) is not allowed.
Rails	config.hosts	403 Forbidden; 開発時はデバッグページ、その他は空の本体; ログの Blocked hosts: 行
Django	ALLOWED_HOSTS	DisallowedHost（SuspiciousOperation を伴う）として 400 Bad Request
Angular (dev server)	allowedHosts in angular.json	同じ Vite のメッセージ
Next.js	allowedDevOrigins	ページは描画される可能性、ただし /_next/webpack-hmr のような開発リソースはブロックされ、端末には Blocked cross-origin request to Next.js dev resource の警告が表示

役に立つルール: エラーメッセージがホスト名と追加すべき内容を指している場合、それはフレームワーク側に到達しており、トンネルは動作しています。設定の修正が目的で、ネットワークの問題解決ではありません。

ワイルドカードの意味をざっと理解

フレームワーク間で“ワイルドカード”の意味は異なり、それが多くの混乱の原因です。

Framework	Syntax	純粋なドメインにマッチしますか？	ネストしたサブドメインにマッチしますか？
Vite	.example.com	はい	はい（ド docs に従えば任意の深さ）
Rails	.example.com	はい	現在のソースでは 1 ラベル分のみ; 古いリリースは緩い
Django	.example.com	はい	はい（“他の任意サブドメイン”）
Next.js	*.example.com	いいえ	いいえ（正確には 1 ラベル）
Next.js	**.example.com	いいえ	はい（1 個以上のラベル）
Angular dev server	Vite と同じ	はい	はい

使っているフレームワークに関係なく、パターンが機能する前に実際のトンネルホスト名をテストしてください。

Vite: server.allowedHosts

Vite は server.allowedHosts を string[] | true としてドキュメント化しており、デフォルトは []。 out-of-the-box では localhost、.localhost 以下の任意のドメイン、そしてすべての IP アドレスを受け付けます。その他はすべて 403 を返します。

このチェックは advisory GHSA-vg6x-rcgg-rjx6 (CVE-2025-24010) の修正とともに導入されました。6.0.9 の changelog には server.allowedHosts を導入した Host-header チェックが記載されています。 advisory の固定バージョンは 6.0.9、5.4.12、4.5.6。これが、数か月間動作していたセットアップでアップグレード時にしばしばエラーを引き起こす理由です。

// vite.config.js
import { defineConfig } from 'vite'

export default defineConfig({
  server: {
    allowedHosts: ['my-app.tunnel.example.com'],
  },
})

知っておくと役立つ細部:

• 先頭のドット。 . で始まる文字列は、ドットを含めずそのサブドメインすべてを許可します。 docs によれば、.example.com は example.com、foo.example.com、foo.bar.example.com をカバーします。自分が所有するドメインに対してのみ使用してください。
• トップレベルドメインの追加は避ける 例として .com のようなものは避けます。ドメインを任意に登録して解決先を決定できるためです。
• 環境変数。 __VITE_ADDITIONAL_SERVER_ALLOWED_HOSTS を設定すると、設定ファイルを触らずにホストを追加できます。複数のホストはカンマで区切ります。CI や個人のトンネル名をコミットしたくない共有リポジトリで便利です。
• vite preview は別。 プレビューサーバーには独自の preview.allowedHosts があり、デフォルトは server.allowedHosts の値です。2つが異なるべき場合にのみ明示的に設定してください。エラーメッセージを読んで、どのブロックを指しているかを確認します。
• 関連設定: server.cors。 同じ advisory は Vite の CORS 処理も変更しました。現在のデフォルトは localhost 形式のオリジンのみを許可します。
• Vite ベースのフレームワーク。 Nuxt は vite.server.allowedHosts を nuxt.config.ts に、Strapi 5 の admin panel も Vite を使用します。Strapi 自体の開発構成は内部的に allowedHosts: true を設定している場合があり、現在のリリースで Strapi をアップグレードすると解決策になる場合があります。ファイルがなくて困っている場合は、フレームワークの設定に vite キーがないか確認してください。

ページが読み込まれてもホットリロードが壊れている場合。 ホストを許可することで初期読み込みは解決しますが、ホットモジュール置換は WebSocket を介して動作します。ポートを書き換えるトンネルはそれを壊すことがあります。Strapi のガイドは ngrok、Cloudflare Tunnel、VS Code のポートフォワードをこの点で指摘します。Vite のドキュメントには WebSocket 設定が server.ws の下に一覧化されており、clientPort などがブラウザが接続するポートを上書きします。古い Vite では server.hmr の WebSocket オプションが現在は推奨されていません。古いバージョンではまだ server.hmr にあることがあります。

フォーラムでよく見かけるショートカットは allowedHosts: true ですが、これがなぜデフォルトとして悪いのかは後述します。

Rails: config.hosts

Rails はこれをホスト認証と呼び、ActionDispatch::HostAuthorization によって実装されています。開発環境ではデフォルトの許可リストは .localhost、.test、およびすべての IPv4/IPv6 アドレスです。他の環境では config.hosts はデフォルトで空です。空のときはミドルウェアは何もしないため、チェックは主に開発時または自分でホストを設定したときにのみ作用します。

# config/environments/development.rb
config.hosts << "my-app.tunnel.example.com"

ソースから読み取れる点:

• 文字列はポートを伴う場合もホストと照合します。先頭にドットを付ける文字列（例 .example.com）はアペックスドメインとサブドメインをマッチさせます。現在のソースでは 1 ラベルのみを許容します（複数の Rails バージョン間で挙動が異なることがあります）。
• 正規表現、IP 範囲、ラムダ も受け入れられます。エントリは === で比較されるため、ラムダは動的チェックを提供します。文字列と正規表現はポートと先頭のドット処理を受け、ラムダはそうではありません。
• X-Forwarded-Host もチェック対象。 プロキシが前面にある場合、Host または最後の X-Forwarded-Host が許可されていないとリクエストをブロックします。
• ルートごとのオプトアウト。 config.host_authorization = { exclude: (request) => { request.path =~ /healthcheck/ } } のように、一致するリクエストのチェックをスキップできます。
• レスポンスは 403 Forbidden、ブロックされたホストはログの error レベルで記録されます。本文は config.consider_all_requests_local が true の場合のみデバッグ情報を含みます。そうでなければ空で、運用時のブロックを謎に見せることがあります。
• Rails を最新に保つ。 先頭ドットのエントリと X-Forwarded-Host ヘッダを含むリクエストは過去のアドバイザリの対象でした。

空の config.hosts はチェックを無効化します。Rails では config.hosts.clear が Vite の true の等価物です。これと同じ扱いにしてください。

Django: ALLOWED_HOSTS

Django は 1.4.4（2013 年 2 月 19 日）に Host ヘッダ汚染対策として ALLOWED_HOSTS を導入しました。当時のデフォルトは backwards compatibility のため ['*'] でしたが、現在のデフォルトは空リストです。

DEBUG = False の場合、空リストだとすべてのリクエストが Bad Request（400）で失敗します。DEBUG = True かつ空リストの場合、現在のドキュメントではホストは ['.localhost', '127.0.0.1', '[::1]'] に対して検証されるため、トンネル名はデバッグモードでも失敗します。

このデバッグ動作には歴史的な背景があります。古いバージョンでは DEBUG=True のときチェックをスキップしており、DNS リバインディング攻撃を許していました（CVE-2016-9014）。Django は 1.10.3、1.9.11、1.8.16 で修正しました。

# settings.py
ALLOWED_HOSTS = ["my-app.tunnel.example.com"]

• 正確なマッチング。 名前は Host ヘッダと大文字小文字を区別せず、ポートを無視して比較されます。末尾のドット（FQDN 形式）は比較前に削除されます。
• ** Leading period as wildcard.** .example.com は example.com、www.example.com、および任意のサブドメインにマッチします。ドキュメントには 2 種類のワイルドカードしか記載されていません：先頭のドットと bare *。*.example.com は公式には記載されていません。
• USE_X_FORWARDED_HOST。 有効化すると Django は Host の代わりに X-Forwarded-Host を検証します。
• バイパスの警告。 get_host() で検証が行われ、request.META からヘッダを直接読むコードは検証を回避します。

トンネルを通じてページが読み込まれた後でも、フォームのポストが Django の CSRF Origin チェックに失敗することがあります。ブラウザの Origin はトンネルの https:// URL であり、Django は一致させる必要があります。完全な Origin（スキームを含む）を CSRF_TRUSTED_ORIGINS に追加してください。この設定は https://*.example.com のようなサブドメインワイルドカードをサポートします。トンネルが平文 HTTP を転送している場合は、SECURE_PROXY_SSL_HEADER が適切かも確認してください。プロキシが X-Forwarded-Proto ヘッダを確実に制御している場合にのみ設定します。

Angular: allowedHosts in angular.json

Angular の現代的な開発サーバーは Vite 上で動作するため、Vite のエラーを受け取りますが、編集する vite.config.js はありません。Angular CLI は開発サーバー用の allowedHosts オプションを追加しました（PR #29466、2025年1月）。Vite 6.0.9 以降への移行後に追加されたものです。CLI のドキュメントは、開発サーバーが応答するホストとしての意味と、Vite の同名オプションを設定することを説明しています。

"serve": {
  "builder": "@angular/build:dev-server",
  "options": {
    "allowedHosts": ["my-app.tunnel.example.com"]
  }
}

webpack ベースのビルダー (@angular-devkit/build-angular:dev-server) も同じオプションを同じ場所で受け付けます。CLI 自身のテストは、リストにあるホストは通過、true は任意のホストを許可、空配列は未知のホストを拒否、という 3 つの挙動を確認しています。CLI は --allowed-hosts というオプション名も公開します。

Angular にはもう一つ別のホストチェックがあり、最初のものと混同しやすいです。サーバーサイドレンダリングは SSRF 対策としてリクエストのホスト名を検証しますが、そのメッセージは Vite の文言を使用しません:

• Host http://localhost:4200/ is not allowed. You can configure allowedHosts option. SSR プロジェクトでの ng serve に関する報告（ Issue #33184 ）
• URL with hostname "..." is not allowed. Please provide a list of allowed hosts in the "allowedHosts" option in the "CommonEngine" constructor. は @angular/ssr 21.1.5 の後に報告されました。ロードバランサの背後で内部 IP が公開名として見えるケースでの報告です（ Issue #32616 ）。

SSR の場合、CommonEngine のコンストラクタ、angular.json のビルドオプション、NG_ALLOWED_HOSTS 環境変数のいずれかで allowedHosts を設定できます。環境変数を使って localhost のケースを解決したという報告もあります。文字列は正確なホスト名、または *.domain のようなワイルドカード接頭辞を受け付け、任意のパターンは受け付けない、という点を覚えておいてください。エラーテキストが Vite の文と異なる場合、これは二層目のチェックです。serve.options の編集だけでは解決しません。

SSR の許可リスト自体も修正されています。Next.js 15.2.2 および 14.2.30 での CVE-2026-50168 への対応として、修正はオプトイン形式で allowedDevOrigins を設定する、という説明になっています。早期バージョンでは警告のみでした。2026年3月の変更（PR #91507）で警告のみのデフォルトが削除され、デフォルトでブロックするようになりました。現在のドキュメントはそのように説明しています。古いリリースの場合はそのバージョンのドキュメントが適用されます。

もしトンネル経由でページが表示されるものの、対話的な挙動が壊れている場合、ターミナルに Blocked cross-origin request to Next.js dev resource の警告が表示される場合は、この設定が原因です。Next.js もパッチを適用しましょう。CVE-2026-27977 は Origin: null が WebSocket のオリジン保護を回避することを許してしまうため、16.0.1 から 16.1.7 まで影響します（ allowedDevOrigins が設定されていた場合でも）。

安定したサブドメインがあると1回限りの設定になる理由

許可リストは設計上厳密です。そのため public ホスト名が頻繁に変わるとコストが発生します。

毎回開始時にランダムなホスト名を割り当てる一時的なトンネルを使用している場合、セッションごとに許可リストを編集します。各編集はコミットに残る設定ファイルの変更であり、チームメンバー全員が異なる名前を持ちます。こうした疲労感が allowedHosts: true がリポジトリに現れる理由です。

一方、予約済みで安定したサブドメイン があると、ホスト名を開始前に知ることができます。my-app.tunnel.example.com を一度だけ許可リストに追加してコミットすれば、以降は誰もが同じ名前を指すようになり、OAuth のリダイレクト URI、ウェブフックのエンドポイント、CSRF trusted origins、保存したブックマークなどすべてが安定します。エラーの発生はたちまち収まります。

もしホスト名が個人用で共有されない場合は、リポジトリに入れず、環境変数から読み込む方法を選んでください。

// vite.config.js
server: {
  allowedHosts: process.env.TUNNEL_HOST ? [process.env.TUNNEL_HOST] : [],
}

# config/environments/development.rb
config.hosts << ENV["TUNNEL_HOST"] if ENV["TUNNEL_HOST"]

同じパターンは settings.py の環境変数や next.config.js の process.env を使った場合にも有効です。

allowedHosts: true の罠

上記のチェックを無効化するのは、以下の 1 行です：Vite の true、Rails の config.hosts.clear、Django の '*'、あるいは Angular の dev-server オプションの true。この設定はエラーを即座に解決しますが、同時に重大なリスクを生みます。

Vite のドキュメントはこの点を端的に指摘します。server.allowedHosts を true に設定すると、DNS リバインディング攻撃を通じて任意のウェブサイトがあなたの開発サーバーへリクエストを送れるようになり、ソースコードやコンテンツをダウンロードさせてしまいます。常に明示的なリストを使用することを推奨します。つまり、元々あった制御機能を自らオフにしてしまうのです。

慎重さを欠くと起こりがちな 2 つの誤り:

1. 共有ドメインの許可。 例として .ngrok-free.app のような共有ドメインをリストに加えると、自分が管理していないドメインへ信頼を拡張してしまいます。Vite の方針は、解決できるホスト名のみ、あるいは自身が所有する完全なホスト名を許可することです。自分が所有する完全なホスト名を優先してください。
2. デモ用途の“とりあえず許可”。開発サーバーはデモの期日を過ぎても動作します。明示的なホスト名を残しておくのが最良です。

コピー＆ペーストチェックリスト

1. エラーメッセージがホスト名と設定を名指ししているか確認します。設定を修正し、トンネルを修正するのではなく、構成を正します。
2. 公開URL から正確なホスト名をコピーします。スキームやポートは不要です。
3. 適切な箇所に追加します：server.allowedHosts、config.hosts、ALLOWED_HOSTS、Angular の allowedHosts（angular.json）、または allowedDevOrigins。
4. 開発サーバーを再起動します。こうした設定は通常起動時に読み込まれます。
5. ページが読み込まれてもホットリロードやフォーム送信が失敗する場合は、HMR WebSocket 設定（Vite）、Django の CSRF_TRUSTED_ORIGINS、Next.js の dev resource 警告を確認します。
6. 安定したサブドメインを確保して、これを最後に編集するようにします。
7. 自分のネットワークの外部から検証します。例えばセルラーデータのスマホなどを使い、自己のマシンのみから検証しないでください。
8. true、'*'、共有プロバイダのサフィックスを決してコミットしないでください。

FAQ

localhost で動作するのにトンネル経由だと動かないのはなぜですか？

localhost では Host ヘッダは localhost となり、上記のフレームワークではデフォルトで許可されます。しかしトンネル経由では公開ホスト名が使われ、デフォルトリストには載っていません。

allowedHosts: true はいつ許容されますか？

自分と自分が管理するネットワーク内で、短期間だけで、機密情報が含まれていない場合に限ります。たとえ許可しても、明示的なホスト名を指定する方が安全です。

ポートも許可する必要がありますか？

いいえ。Django はホスト名のみをポートなしで照合します。Rails はポートを任意で受け付けます。Next.js のエントリはポートなしで記述します。

エラーには vite.config.js と表示されますが、私のフレームワークにはファイルがありません。どうすれば？

パススルーキーを探してください：Nuxt の vite.server.allowedHosts、Strapi の管理者 Vite 設定（Strapi をアップグレードする場合）、そして Angular の angular.json の allowedHosts。

本番運用に影響しますか？

これらは Vite、Angular、Next.js の開発サーバー設定です。Rails や Django は別です。Django の ALLOWED_HOSTS は本番環境にも適用され、Rails の config.hosts は設定されている環境で有効です。

参考資料

• Vite, Server Options および Preview Options
• Vite advisory GHSA-vg6x-rcgg-rjx6
• Rails API, ActionDispatch::HostAuthorization および pull request #33145
• Django, Settings: ALLOWED_HOSTS and CSRF_TRUSTED_ORIGINS, 1.4.4 release notes および 2016 security releases
• Angular CLI, ng serve options, pull request #29466, issue #33184 および issue #32616
• Angular advisory GHSA-xrxm-cp7j-8xf6
• Next.js, allowedDevOrigins, advisory GHSA-3h52-269p-cp9r, pull request #91507 および CVE-2026-27977
• Strapi, Fixing “Blocked request. This host is not allowed” in Strapi 5
• Nuxt example, Fixing ‘Blocked request’ When Exposing a Nuxt 3 Dev Server Through ngrok