Google は、黒人コミュニティのための人種的公平の促進に取り組んでいます。詳細をご覧ください。

ホスティング動作を構成する

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

Hosting の構成で可能なこと

Hosting の構成を定義する場所

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

このページの最後に、firebase.json の構成例(Firebase Hosting のみを対象)を紹介します。firebase.json ファイルには、他の Firebase サービスの構成も定義できます。

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

Hosting のレスポンスの優先順位

このページで説明する Firebase Hosting 構成オプションが競合する場合があります。競合が発生した場合、Hosting からのレスポンスは次の優先順位に従って決定されます。

  1. /__/* パスセグメントで始まる予約済みの名前空間
  2. リダイレクトの構成
  3. 正確に一致する静的コンテンツ
  4. リライトの構成
  5. カスタムの 404 ページ
  6. デフォルトの 404 ページ

i18n リライトを使用している場合は、スコープ内の完全一致と 404 処理の優先順位が拡張され、「i18n content」が含まれるようにます。

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

デフォルトの firebase.json ファイルに含まれるデフォルトの属性(publicignore)により、プロジェクト ディレクトリ内のどのファイルが Firebase プロジェクトにデプロイされるのかが決まります。

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

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

public

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

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

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

  // ...
}

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

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

  // ...
}

ignore

省略可
ignore 属性には、デプロイ時に無視するファイルを指定します。Git.gitignore と同じように glob を使用できます。

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

"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 にリダイレクトできます。

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

redirects 属性の基本構造は次のとおりです。この例では、/foo に対するリクエストをリダイレクトし、新しいリクエストを /bar に送信します。

"hosting": {
  // ...

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

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

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

フィールド 説明
redirects
source (推奨)
または regex

URL パターンを指定します。この URL パターンが最初のリクエスト URL と一致した場合、リダイレクトの適用がトリガーされます。

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

ブラウザが新しいリクエストを送信する静的 URL

この URL には、相対パス、絶対パスのどちらでも指定できます。

type

HTTP レスポンス コード

  • 「Moved Permanently(恒久的に移動した)」には 301 のタイプを使用します。
  • 「Found(検出)」(一時的なリダイレクト)には 302 のタイプを使用します。

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

省略可
リダイレクト ルールの URL パターン(source または regex の値)の特定のセグメントをキャプチャし、ルールの destination パスでそれらのセグメントを使用しなければならない場合があります。

リライトを構成する

省略可
リライトは、複数の URL で同じコンテンツを表示するために使用します。パターンに一致する URL を受け取って、クライアント側コードで表示内容を決定するようにできるため、パターン マッチングで使用すると特に有用です。

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

URL リライトを指定するには、オブジェクトの配列を含む rewrites 属性を作成します(「リライトルール」と呼ばれます)。それぞれのルールで URL パターンを指定します。この URL パターンがリクエスト URL パスと一致した場合、Hosting の応答がトリガーされ、指定された宛先 URL を提供するように応答が行われます。

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

"hosting": {
  // ...

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

rewrites 属性にはリライトルールの配列が含まれます。それぞれのルールには、以下の表に示すフィールドを含める必要があります。

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

フィールド 説明
rewrites
source (推奨)
または regex

URL パターンを指定します。この URL パターンが最初のリクエスト URL と一致した場合、リライトの適用がトリガーされます。

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

実際に存在するローカル ファイル

この URL には、相対パス、絶対パスのどちらでも指定できます。

関数にリクエストを送信する

rewrites を使用すると、Firebase Hosting の URL から関数を提供できます。次のコードは、Cloud Functions を使用して動的コンテンツを提供する部分を表しています。

たとえば、Hosting サイトの /bigben ページからすべてのリクエストを送信して bigben 関数を実行する場合は、次のようになります。

"hosting": {
  // ...

  // Directs all requests from the page `/bigben` to execute the `bigben` function
  "rewrites": [ {
    "source": "/bigben",
    "function": "bigben"
  } ]
}

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

  • Firebase のサブドメイン:
    PROJECT_ID.web.app/bigbenPROJECT_ID.firebaseapp.com/bigben

  • 接続されたカスタム ドメイン:
    CUSTOM_DOMAIN/bigben

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

rewrites を使用すると、Firebase Hosting の URL から Cloud Run コンテナにアクセスできます。次のコードは、Cloud Run を使用して動的コンテンツを提供する部分を表しています。

たとえば、Hosting サイトのページ(/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 にデプロイすると(firebase deploy を使用)、次の URL からコンテナ イメージにアクセスできるようになります。

  • Firebase のサブドメイン:
    PROJECT_ID.web.app/helloworldPROJECT_ID.firebaseapp.com/helloworld

  • 接続されたカスタム ドメイン:
    CUSTOM_DOMAIN/helloworld

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 のパスのリライトルールとは異なり、Dynamic Links のリライトルールに正規表現を含めることはできません。

dynamicLinks true に設定する必要があります。

ヘッダーを構成する

省略可
ヘッダーを使用すると、クライアントとサーバーはリクエストまたはレスポンスと一緒に追加情報を渡すことができます。ヘッダーの一部は、ブラウザがページとそのコンテンツを処理する方法(アクセス制御、認証、キャッシュ、エンコードなど)に影響を与える可能性があります。

ファイル固有のカスタム レスポンス ヘッダーを指定するには、ヘッダー オブジェクトの配列を含む headers 属性を作成します。各オブジェクトに URL パターンを指定します。この URL パターンがリクエスト 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 属性には定義の配列が含まれます。それぞれの定義には、以下の表に示すフィールドを含める必要があります。

フィールド 説明
headers
source (推奨)
または regex

URL パターンを指定します。この URL パターンが最初のリクエスト URL と一致した場合、カスタム ヘッダーの適用がトリガーされます。

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

カスタム 404 ページに対して照合されるヘッダーを作成するには、source または regex の値として 404.html を使用します。

(sub-)headers の配列

リクエストパスに適用されるカスタム ヘッダー

それぞれのサブヘッダーには keyvalue のペアを含める必要があります(次の 2 行を参照)。

key ヘッダーの名前。例: Cache-Control
value ヘッダーの値。例: max-age=7200

動的コンテンツの提供とマイクロサービスのホスティングの詳細については、Hosting セクションの 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 によって提供される動的コンテンツへのリライトには影響しません。

glob パターン マッチング

Firebase Hosting 構成オプションでは、Git で gitignore ルールを処理する場合や Bowerignore ルールを処理する場合と同様に、extglob を使用する glob パターン マッチング表記を使用します。より詳しい参考資料としては、こちらの Wiki ページをご覧ください。以下では、このページで使用した例について説明します。

  • firebase.json - public ディレクトリのルートにある firebase.json ファイルにのみ一致します。

  • ** - 任意のサブディレクトリ内にあるファイルまたはフォルダと一致します。

  • * - public ディレクトリのルートにあるファイルとフォルダにのみ一致します。

  • **/.* - 任意のサブディレクトリ内にある「.」で始まるファイル(通常は .git フォルダ内などにある非表示ファイル)と一致します。

  • **/node_modules/** - node_modules フォルダの任意のサブディレクトリ内にあるファイルまたはフォルダと一致します。このフォルダ自体が public ディレクトリの任意のサブディレクトリとなります。

  • **/*.@(jpg|jpeg|gif|png) - 任意のサブディレクトリ内にあるファイルで、.jpg.jpeg.gif.png のいずれかで終了するものと一致します。

Hosting の完全な構成の例

以下に、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",

  }
}