このページは Cloud Translation API によって翻訳されました。

ホスティング動作の構成

Firebase Hosting を使用すると、サイトへのリクエストに対してカスタマイズされたホスティング動作を構成できます。

ホスティング用に何を構成できますか?

Firebase Hosting にデプロイするローカルプロジェクトディレクトリ内のファイルを指定します。方法を学ぶ。
カスタマイズされた 404/Not Found ページを提供します。方法を学ぶ。
移動または削除したページのredirectsを設定します。方法を学ぶ。
次のいずれかの目的でrewritesを設定します。
- 複数の URL に対して同じコンテンツを表示します。方法を学ぶ。
- 関数を提供するか、ホスティング URL から Cloud Run コンテナにアクセスします。方法を学ぶ: functionまたはcontainer .
- カスタムドメインのダイナミックリンクを作成します。方法を学ぶ。
headersを追加して、ブラウザーがページとそのコンテンツを処理する方法 (認証、キャッシュ、エンコードなど) など、要求または応答に関する追加情報を渡します。方法を学ぶ。
国際化 (i18n) 書き換えを設定して、ユーザーの言語設定や国に基づいて特定のコンテンツを提供します。方法を学びます（別のページ）。

ホスティング構成はどこで定義しますか?

firebase.jsonファイルで Firebase Hosting 構成を定義します。 firebase firebase initコマンドを実行すると、Firebase はプロジェクトディレクトリのルートにfirebase.jsonファイルを自動的に作成します。

このページの下部に、完全なfirebase.json構成の例(Firebase Hosting のみをカバー) があります。 firebase.jsonファイルには、他の Firebase サービスの構成を含めることもできます。

Hosting REST APIを使用して、デプロイされたfirebase.jsonコンテンツを確認できます。

Hosting レスポンスの優先順位

このページで説明されているさまざまな Firebase Hosting 構成オプションは、重複する場合があります。競合がある場合、Hosting は次の優先順位を使用して応答を決定します。

/__/*パスセグメントで始まる予約済みの名前空間
構成されたリダイレクト
完全一致の静的コンテンツ
構成された書き換え
カスタム 404ページ
デフォルトの 404 ページ

i18n rewritesを使用している場合、「i18n コンテンツ」に対応するために、完全一致と 404 処理の優先順位が範囲内で拡張されます。

デプロイするファイルを指定する

デフォルトのfirebase.jsonファイルに含まれるデフォルトの属性publicとignoreは、プロジェクトディレクトリ内のどのファイルを Firebase プロジェクトにデプロイするかを定義します。

firebase.jsonファイルのデフォルトのhosting構成は次のようになります。

"hosting": {
  "public": "public",  // the only required attribute for Hosting
  "ignore": [
    "firebase.json",
    "**/.*",
    "**/node_modules/**"
  ]
}

公共

必須
public属性は、Firebase Hosting にデプロイするディレクトリを指定します。デフォルト値はpublicという名前のディレクトリですが、プロジェクトディレクトリに存在する限り、任意のディレクトリのパスを指定できます。

デプロイするディレクトリのデフォルトの指定名は次のとおりです。

"hosting": {
  "public": "public"

  // ...
}

デフォルト値を、デプロイするディレクトリに変更できます。

"hosting": {
  "public": "dist/app"

  // ...
}

無視

オプション
ignore属性は、デプロイ時に無視するファイルを指定します。 Gitが.gitignoreを処理するのと同じ方法でグロブを取ることができ.gitignore 。

無視するファイルのデフォルト値は次のとおりです。

"hosting": {
  // ...

  "ignore": [
    "firebase.json",  // the Firebase configuration file (the file described on this page)
    "**/.*",  // files with a leading period should be hidden from the system
    "**/node_modules/**"  // contains dependencies used to create your site but not run it
  ]
}

404/Not Found ページをカスタマイズする

オプション
ユーザーが存在しないページにアクセスしようとすると、カスタム404 Not Foundエラーを提供できます。

プロジェクトのpublicディレクトリに新しいファイルを作成し、 404.htmlという名前を付けてから、カスタム404 Not Foundコンテンツをファイルに追加します。

ブラウザがドメインまたはサブドメインで404 Not Foundエラーをトリガーした場合、Firebase Hosting はこのカスタム404.htmlページのコンテンツを表示します。

リダイレクトを構成する

オプション
URL リダイレクトを使用して、ページを移動した場合にリンクが壊れないようにしたり、URL を短くしたりします。たとえば、ブラウザをexample.com/teamからexample.com/about.htmlにリダイレクトできます。

オブジェクトの配列を含むredirects属性を作成して、URL リダイレクトを指定します (「リダイレクトルール」と呼ばれます)。各ルールで、リクエスト URL パスに一致する場合に Hosting が指定された宛先 URL へのリダイレクトで応答するようにトリガーする URL パターンを指定します。

これがredirects属性の基本構造です。この例では、 /barに新しいリクエストを作成することで、リクエストを/fooにリダイレクトします。

"hosting": {
  // ...

  // Returns a permanent redirect to "/bar" for requests to "/foo" (but not "/foo/**")
  "redirects": [ {
    "source": "/foo",
    "destination": "/bar",
    "type": 301
  } ]
}

redirects属性のより詳細な例を見る

"hosting": {
  // ...

  // Add the "redirects" attribute within "hosting"
  "redirects": [ {
    // Returns a permanent redirect to "/bar" for requests to "/foo" (but not "/foo/**")
    "source": "/foo",
    "destination": "/bar",
    "type": 301
  }, {
    // Returns a permanent redirect to "/bar" for requests to both "/foo" and "/foo/**"
    "source": "/foo{,/**}"
    "destination": "/bar"
    "type": 301
  }, {
    // Returns a temporary redirect for all requests to files or directories in the "firebase" directory
    "source": "/firebase/**",
    "destination": "https://firebase.google.com/",
    "type": 302
  }, {
    // A regular expression-based redirect equivalent to the above behavior
    "regex": "/firebase/.*",
    "destination": "https://firebase.google.com/",
    "type": 302
  } ]
}

redirects属性には、リダイレクトルールの配列が含まれます。各ルールには、以下の表のフィールドを含める必要があります。

Firebase Hosting は、すべてのリクエストの開始時 (ファイルまたはフォルダーがそのパスに存在するかどうかをブラウザーが判断する前) に、 sourceまたはregexの値をすべての URL パスと比較します。一致が見つかった場合、Firebase Hosting オリジンサーバーは HTTPS リダイレクトレスポンスを送信し、 destination URL で新しいリクエストを行うようにブラウザに指示します。

分野		説明
`redirects`
	`source` (推奨) または`regex`	最初のリクエスト URL と一致した場合に Hosting がリダイレクトを適用するようにトリガーする URL パターン `source`を使用してglobを指定します(推奨) 。 `regex`を使用してRE2 正規表現を指定します。
	`destination`	ブラウザが新しいリクエストを行う静的 URL この URL は、相対パスまたは絶対パスにすることができます。
	`type`	HTTPS 応答コード「Moved Permanently」にはタイプ`301`を使用します「Found」にはタイプ`302`を使用します (一時的なリダイレクト)

リダイレクト用の URL セグメントをキャプチャする

オプション
場合によっては、リダイレクトルールの URL パターン ( sourceまたはregex値) の特定のセグメントをキャプチャし、ルールのdestinationパスでこれらのセグメントを再利用する必要がある場合があります。

glob の使用時に URL セグメントをキャプチャする

sourceフィールドを使用している (つまり、URL パターンに glob を指定している) 場合は、セグメントを識別するために:プレフィックスを含めることで、セグメントをキャプチャできます。セグメントの後の残りの URL パスも取得する必要がある場合は、セグメントの直後に*を含めます。例えば：

"hosting": {
  // ...

  "redirects": [ {
    "source": "/blog/:post*",  // captures the entire URL segment beginning at "post"
    "destination": "https://blog.myapp.com/:post", // includes the entire URL segment identified and captured by the "source" value
    "type": 301
  }, {
    "source": "/users/:id/profile",  // captures only the URL segment "id", but nothing following
    "destination": "/users/:id/newProfile",  // includes the URL segment identified and captured by the "source" value
    "type": 301
  } ]
}

RE2 正規表現を使用して URL セグメントをキャプチャする

regexフィールドを使用している場合 (つまり、URL パターンに RE2 正規表現を指定している場合)、名前付きまたは名前なしの RE2 キャプチャグループを使用してセグメントをキャプチャできます。名前付きのキャプチャグループはdestinationフィールドで:プレフィックスを使用して使用できますが、名前のないキャプチャグループは、1 からregex値の数値インデックスで参照できます。次に例を示します。

"hosting": {
  // ...

  "redirects": [ {
    "regex": "/blog/(?P<post>.+)",  // if you're familiar with PCRE, be aware that RE2 requires named capture groups to begin with ?P
    "destination": "https://blog.myapp.com/:post",  // includes the entire URL segment identified and captured by the `regex` value
    "type": 301
  }, {
    "regex": "/users/(\d+)/profile",  // uses the \d directive to only match numerical path segments
    "destination": "/users/:1/newProfile",  // the first capture group to be seen in the `regex` value is named 1, and so on
    "type": 301
  } ]
}

書き換えを構成する

オプション
書き換えを使用して、複数の URL に対して同じコンテンツを表示します。書き換えは、パターンマッチングで特に役立ちます。パターンに一致する任意の URL を受け入れ、クライアント側のコードに何を表示するかを決定させることができるからです。

書き換えを使用して、ナビゲーションにHTML5 pushStateを使用するアプリをサポートすることもできます。ブラウザーが、指定されたsourceまたはregex URL パターンに一致する URL パスを開こうとすると、ブラウザーには、代わりにdestination URL にあるファイルの内容が表示されます。

オブジェクトの配列を含むrewrites属性を作成して、URL 書き換えを指定します (「書き換えルール」と呼ばれます)。各ルールで、要求 URL パスに一致した場合に Hosting をトリガーして、指定された宛先 URL がサービスに与えられたかのように応答する URL パターンを指定します。

rewrites属性の基本構造は次のとおりです。この例では、存在しないファイルまたはディレクトリへのリクエストに対してindex.htmlを提供します。

"hosting": {
  // ...

  // Serves index.html for requests to files or directories that do not exist
  "rewrites": [ {
    "source": "**",
    "destination": "/index.html"
  } ]
}

rewrites属性のより詳細な例を見る

"hosting": {
// ...

// Add the "rewrites" attribute within "hosting"
"rewrites": [ {
  // Serves index.html for requests to files or directories that do not exist
  "source": "**",
  "destination": "/index.html"
}, {
  // Serves index.html for requests to both "/foo" and "/foo/**"
  // Using "/foo/**" only matches paths like "/foo/xyz", but not "/foo"
  "source": "/foo{,/**}",
  "destination": "/index.html"
}, {
  // A regular expression-based rewrite equivalent to the above behavior
  "regex": "/foo(/.*)?",
  "destination": "/index.html"
}, {
  // Excludes specified pathways from rewrites
  "source": "!/@(js|css)/**",
  "destination": "/index.html"
} ]
}

rewrites属性には、一連の書き換えルールが含まれます。各ルールには、次の表のフィールドを含める必要があります。

Firebase Hosting は、指定されたsourceまたはregex URL パターンに一致する URL パスにファイルまたはディレクトリが存在しない場合にのみ、書き換えルールを適用します。要求が書き換えルールをトリガーすると、ブラウザは HTTP リダイレクトではなく、指定されたdestinationファイルの実際のコンテンツを返します。

分野説明

分野	説明
`rewrites`
	`source` (推奨) または`regex`	最初のリクエスト URL と一致した場合に Hosting をトリガーして書き換えを適用する URL パターン `source`を使用してglobを指定します(推奨) 。 `regex`を使用してRE2 正規表現を指定します。
	`destination`	存在する必要があるローカルファイルこの URL は、相対パスまたは絶対パスにすることができます。

rewrites

source (推奨)
またはregex

最初のリクエスト URL と一致した場合に Hosting をトリガーして書き換えを適用する URL パターン

sourceを使用してglobを指定します(推奨) 。
regexを使用してRE2 正規表現を指定します。

destination

存在する必要があるローカルファイル

この URL は、相対パスまたは絶対パスにすることができます。

関数への直接リクエスト

rewritesを使用して、Firebase Hosting URL から関数を提供できます。次の例は、 Cloud Functions を使用した動的コンテンツの提供からの抜粋です。

たとえば、ホスティングサイトのページ/bigbenからのすべての要求を、 bigben関数を実行するように指示するには:

"hosting": {
  // ...

  // Directs all requests from the page `/bigben` to execute the `bigben` function
  "rewrites": [ {
    "source": "/bigben",
    "function": "bigben",
    "region": "us-central1"  // optional (see note below)
  } ]
}

この書き換えルールを追加し、( firebase deployを使用して) Firebase にデプロイすると、次の URL を介して関数にアクセスできるようになります。

Firebase サブドメイン:
PROJECT_ID .web.app/bigbenおよびPROJECT_ID .firebaseapp.com/bigben
接続されているカスタムドメイン:
CUSTOM_DOMAIN /bigben

Hosting でリクエストを関数にリダイレクトする場合、サポートされている HTTP リクエストメソッドはGET 、 POST 、 HEAD 、 PUT 、 DELETE 、 PATCH 、およびOPTIONSです。 REPORTやPROFINDなどの他の方法はサポートされていません。

リクエストを Cloud Run コンテナに転送する

rewritesを使用して、Firebase Hosting URL から Cloud Run コンテナにアクセスできます。次の例は、 Cloud Run を使用した動的コンテンツの提供からの抜粋です。

たとえば、ホスティングサイトのページ/helloworldからのすべての要求を、 helloworldコンテナーインスタンスの起動と実行をトリガーするように指示するには、次のようにします。

"hosting": {
 // ...

 // Directs all requests from the page `/helloworld` to trigger and run a `helloworld` container
 "rewrites": [ {
   "source": "/helloworld",
   "run": {
     "serviceId": "helloworld",  // "service name" (from when you deployed the container image)
     "region": "us-central1"  // optional (if omitted, default is us-central1)
   }
 } ]
}

この書き換えルールを追加し、( firebase deployを使用して) Firebase にデプロイすると、次の URL からコンテナーイメージにアクセスできるようになります。

Firebase サブドメイン:
PROJECT_ID .web.app/helloworldおよびPROJECT_ID .firebaseapp.com/helloworld
接続されているカスタムドメイン:
CUSTOM_DOMAIN /helloworld

Hosting を使用してリクエストを Cloud Run コンテナにリダイレクトする場合、サポートされている HTTP リクエストメソッドはGET 、 POST 、 HEAD 、 PUT 、 DELETE 、 PATCH 、およびOPTIONSです。 REPORTやPROFINDなどの他の方法はサポートされていません。

現在、次のリージョンの Hosting で Cloud Run の書き換えを使用できます。

asia-east1
asia-east2
asia-northeast1
asia-northeast2
asia-northeast3
asia-south1
asia-southeast1
asia-southeast2
australia-southeast1
europe-north1
europe-west1
europe-west2
europe-west3
europe-west4
europe-west6
northamerica-northeast1
southamerica-east1
us-central1
us-east1
us-east4
us-west1

カスタムドメインの Dynamic Links を作成する

rewritesを使用して、カスタムドメインの Dynamic Links を作成できます。 Dynamic Linksのカスタムドメインの設定について詳しくは、Dynamic Links のドキュメントをご覧ください。

Dynamic Links にのみカスタムドメインを使用する

"hosting": {
  // ...

  "appAssociation": "AUTO",  // required for Dynamic Links (default is AUTO if not specified)

  // Add the "rewrites" attribute within "hosting"
  "rewrites": [ {
    "source": "/**",  // the Dynamic Links start with "https://CUSTOM_DOMAIN/"
    "dynamicLinks": true
  } ]
}

Dynamic Links に使用するカスタムドメインパスプレフィックスを指定する

"hosting": {
  // ...

  "appAssociation": "AUTO",  // required for Dynamic Links (default is AUTO if not specified)

  // Add the "rewrites" attribute within "hosting"
  "rewrites": [ {
    "source": "/promos/**",  // the Dynamic Links start with "https://CUSTOM_DOMAIN/promos/"
    "dynamicLinks": true
  }, {
    "source": "/links/share/**",  // the Dynamic Links start with "https://CUSTOM_DOMAIN/links/share/"
    "dynamicLinks": true
  } ]
}

firebase.jsonファイルで Dynamic Links を構成するには、以下が必要です。

分野		説明
`appAssociation`		`AUTO`に設定する必要がありますこの属性を構成に含めない場合、 `appAssociation`のデフォルトは`AUTO`です。この属性を`AUTO`に設定すると、Hosting は、 `assetlinks.json`と`apple-app-site-association`ファイルが要求されたときに動的に生成できます。
`rewrites`
	`source`	Dynamic Links に使用するパス URL へのパスを書き換えるルールとは異なり、ダイナミックリンクの書き換えルールには正規表現を含めることはできません。
	`dynamicLinks`	`true`に設定する必要があります

重要: Dynamic Links の場合、ホスティングの優先順位に特に注意してください。

Dynamic Links の URL プレフィックスが優先度の高いホスティング構成と競合しないようにしてください (たとえば、ホストされている静的コンテンツは常に書き換えよりも優先されます)。
各redirectsおよびrewrites属性内で、ホスティングは、要求されたパスに一致する URL パターンを持つ最初のルールによって定義されたリダイレクトまたは書き換えを適用します。そのため、 redirects属性とrewrites属性のそれぞれでルールを慎重に並べ替える必要があります。

詳細については、 Dynamic Links のドキュメントを参照してください。

ヘッダーを構成する

オプション
ヘッダーを使用すると、クライアントとサーバーは要求または応答と共に追加情報を渡すことができます。一部のヘッダーセットは、アクセス制御、認証、キャッシュ、エンコーディングなど、ブラウザーがページとそのコンテンツを処理する方法に影響を与える可能性があります。

ヘッダーオブジェクトの配列を含むheaders属性を作成して、カスタムのファイル固有の応答ヘッダーを指定します。各オブジェクトで、リクエスト URL パスに一致する場合に Hosting をトリガーして指定されたカスタムレスポンスヘッダーを適用する URL パターンを指定します。

headers属性の基本構造は次のとおりです。この例では、すべてのフォントファイルに CORS ヘッダーを適用します。

"hosting": {
  // ...

  // Applies a CORS header for all font files
  "headers": [ {
    "source": "**/*.@(eot|otf|ttf|ttc|woff|font.css)",
    "headers": [ {
      "key": "Access-Control-Allow-Origin",
      "value": "*"
    } ]
  } ]
}

headers属性のより詳細な例を見る

"hosting": {
  // ...

  // Add the "headers" attribute within "hosting"
  "headers": [ {
    // Applies a CORS header for all font files
    "source": "**/*.@(eot|otf|ttf|ttc|woff|font.css)",
    "headers": [ {
      "key": "Access-Control-Allow-Origin",
      "value": "*"
    } ]
  }, {
    // Overrides the default 1 hour browser cache with a 2 hour cache for all image files
    "source": "**/*.@(jpg|jpeg|gif|png)",
    "headers": [ {
      "key": "Cache-Control",
      "value": "max-age=7200"
    } ]
  }, {
    // A regular expression-based rewrite equivalent to the above behavior
    "regex": ".+/\w+\.(jpg|jpeg|gif|png)$",
    "headers": [ {
      "key": "Cache-Control",
      "value": "max-age=7200"
    } ]
  }, {
    // Sets the cache header for 404 pages to cache for 5 minutes
    "source": "404.html",
    "headers": [ {
      "key": "Cache-Control",
      "value": "max-age=300"
    } ]
  } ]
}

headers属性には一連の定義が含まれており、各定義には次の表のフィールドが含まれている必要があります。

分野			説明
`headers`
	`source` (推奨) または`regex`		最初のリクエスト URL と一致した場合に Hosting をトリガーしてカスタムヘッダーを適用する URL パターン `source`を使用してglobを指定します(推奨) 。 `regex`を使用してRE2 正規表現を指定します。カスタム 404 ページと照合するヘッダーを作成するには、 `source`または`regex`値として`404.html`を使用します。
	(サブ) `headers`の配列		Hosting がリクエストパスに適用するカスタムヘッダー各サブヘッダーには、 `key`と`value`のペアを含める必要があります (次の 2 行を参照)。
		`key`	`Cache-Control`などのヘッダーの名前
		`value`	ヘッダーの値、たとえば`max-age=7200`

Cache-Control詳細については、動的コンテンツの提供とマイクロサービスのホスティングについて説明しているホスティングセクションを参照してください。 CORSヘッダーについても詳しく知ることができます。

`.html`拡張子を制御する

オプション
cleanUrls属性を使用すると、URL に.html拡張子を含めるかどうかを制御できます。

true 、Hosting はアップロードされたファイル URL から.html拡張子を自動的に削除します。リクエストに.html拡張子が追加されている場合、Hosting は同じパスに301リダイレクトを実行しますが、 .html拡張子は削除します。

cleanUrls属性を含めて、URL に.htmlを含めることを制御する方法を次に示します。

"hosting": {
  // ...

  // Drops `.html` from uploaded URLs
  "cleanUrls": true
}

末尾のスラッシュを制御する

オプション
trailingSlash属性を使用すると、静的コンテンツの URL に末尾のスラッシュを含めるかどうかを制御できます。

true 、Hosting は URL をリダイレクトして、末尾にスラッシュを追加します。
falseの場合、Hosting は URL をリダイレクトして末尾のスラッシュを削除します。
指定しない場合、Hosting はディレクトリインデックスファイル (たとえば、 about/index.html ) の末尾のスラッシュのみを使用します。

ここでは、 trailingSlash属性を追加して末尾のスラッシュを制御する方法を示します。

"hosting": {
  // ...

  // Removes trailing slashes from URLs
  "trailingSlash": false
}

trailingSlash属性は、Cloud Functions または Cloud Run によって提供される動的コンテンツへの書き換えには影響しません。

グロブパターンマッチング

Firebase Hosting の構成オプションは、Git がgitignoreルールを処理し、 Bowerがignoreルールを処理する方法と同様に、extglob を使用したglob パターンマッチング表記を広範囲に使用します。この wiki ページはより詳細なリファレンスですが、以下はこのページで使用されている例の説明です:

firebase.json — publicディレクトリのルートにあるfirebase.jsonファイルのみに一致します
** — 任意のサブディレクトリ内の任意のファイルまたはフォルダーに一致します
* — publicディレクトリのルートにあるファイルとフォルダーのみに一致します
**/.* — . で始まるすべてのファイルに一致します. (通常、 .gitフォルダーなどの隠しファイル) 任意のサブディレクトリ内
**/node_modules/** — node_modulesフォルダーの任意のサブディレクトリにある任意のファイルまたはフォルダーに一致し、それ自体がpublicディレクトリの任意のサブディレクトリにある場合があります
**/*.@(jpg|jpeg|gif|png) — .jpg 、 .jpeg 、 .gif 、または.pngのいずれかで終わる任意のサブディレクトリ内の任意のファイルに一致します。

フルホスティングの構成例

以下は、Firebase Hosting の完全なfirebase.json構成の例です。 firebase.jsonファイルには、他の Firebase サービスの構成を含めることもできます。

{
  "hosting": {

    "public": "dist/app",  // "public" is the only required attribute for Hosting

    "ignore": [
      "firebase.json",
      "**/.*",
      "**/node_modules/**"
    ],

    "redirects": [ {
      "source": "/foo",
      "destination": "/bar",
      "type": 301
    }, {
      "source": "/firebase/**",
      "destination": "https://www.firebase.com",
      "type": 302
    } ],

    "rewrites": [ {
      // Shows the same content for multiple URLs
      "source": "/app/**",
      "destination": "/app/index.html"
    }, {
      // Configures a custom domain for Dynamic Links
      "source": "/promos/**",
      "dynamicLinks": true
    }, {
      // Directs a request to Cloud Functions
      "source": "/bigben",
      "function": "bigben"
    }, {
      // Directs a request to a Cloud Run containerized app
      "source": "/helloworld",
      "run": {
        "serviceId": "helloworld",
        "region": "us-central1"
      }
    } ],

    "headers": [ {
      "source": "**/*.@(eot|otf|ttf|ttc|woff|font.css)",
      "headers": [ {
        "key": "Access-Control-Allow-Origin",
        "value": "*"
      } ]
    }, {
      "source": "**/*.@(jpg|jpeg|gif|png)",
      "headers": [ {
        "key": "Cache-Control",
        "value": "max-age=7200"
      } ]
    }, {
      "source": "404.html",
      "headers": [ {
        "key": "Cache-Control",
        "value": "max-age=300"
      } ]
    } ],

    "cleanUrls": true,

    "trailingSlash": false,

    // Required to configure custom domains for Dynamic Links
    "appAssociation": "AUTO",

  }
}