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

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

Hosting で構成できる内容

• ローカル プロジェクト ディレクトリにあるファイルの中から、Firebase Hosting にデプロイするファイルを指定します。詳しくはこちらをご覧ください。

• カスタマイズされた 404/Not Found ページを提供します。詳しくはこちらをご覧ください。

• 移動または削除したページの redirects を設定します。詳しくはこちらをご覧ください。

• 次の目的で rewrites を設定します。

  • 複数の URL で同じコンテンツを表示します。詳しくはこちらをご覧ください。

  • Hosting URL から関数を実行するか、Cloud Run コンテナにアクセスします。方法については、関数またはcontainerをご覧ください。

  • カスタム ドメイン Dynamic Link を作成します。詳しくはこちらをご覧ください。

• headers を追加して、リクエストまたはレスポンスに関する詳細情報を渡します。たとえば、ブラウザがページやコンテンツをどのように処理すべきかに関する情報を渡すことができます（認証、キャッシュ、エンコードなど）。詳しくはこちらをご覧ください。

• 国際化（i18n）リライトを設定し、ユーザーの言語設定または国に基づいて特定のコンテンツを提供します。詳しくはこちらをご覧ください（別のページに移動します）。

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 ファイルに含まれるデフォルトの属性（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 と同じように 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 パスと一致した場合、指定された　Hosting　宛先 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
  } ]
}

"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 に新しいリクエストを送信するようにブラウザに指示します。

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

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

"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
  } ]
}

"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 のファイルのコンテンツが表示されます。

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"
  } ]
}

"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 を使用すると、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": {
      "functionId": "bigben",
      "region": "us-central1"  // optional (see note below)
      "pinTag": true           // optional (see note below)
    }
  } ]
}

このリライトルールを追加して Firebase にデプロイすると（firebase deploy を使用）、次の 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 を使用して動的コンテンツを提供する部分を表しています。

たとえば、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/helloworld と PROJECT_ID.firebaseapp.com/helloworld

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

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

最適なパフォーマンスを得るには、次のリージョンを使用して、Cloud Run サービスを Hosting と同じ場所に配置します。

• us-west1
• us-central1
• us-east1
• europe-west1
• asia-east1

Hosting から Cloud Run への書き換えは、次のリージョンでサポートされています。

• asia-east1
• asia-east2
• asia-northeast1
• asia-northeast2
• asia-northeast3
• asia-south1
• asia-south2
• asia-southeast1
• asia-southeast2
• australia-southeast1
• australia-southeast2
• europe-central2
• europe-north1
• europe-southwest1
• europe-west1
• europe-west12
• europe-west2
• europe-west3
• europe-west4
• europe-west6
• europe-west8
• europe-west9
• me-central1
• me-west1
• northamerica-northeast1
• northamerica-northeast2
• southamerica-east1
• southamerica-west1
• us-central1
• us-east1
• us-east4
• us-east5
• us-south1
• us-west1
• us-west2
• us-west3
• us-west4
• us-west1
• us-central1
• us-east1
• europe-west1
• asia-east1

カスタム ドメインを作成する 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 を構成するには、次のことを行う必要があります。

ヘッダーを構成する

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

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

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": "*"
    } ]
  } ]
}

"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 属性には定義の配列が含まれます。それぞれの定義には、以下の表に示すフィールドを含める必要があります。

動的コンテンツの提供とマイクロサービスのホスティングの詳細については、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 ルールを処理する場合や 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 のいずれかで終了するものと一致します。

完全な 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",

  }
}