静的サイトを複数ホスティングで並走させると、切り戻し先を持てる一方で、設定差分も増えます。
この記事は、Firebase / Netlify / Render / Vercel を並走させるときに見る項目をチェックリストとして整理したものです。
note 版: https://note.com/lazy_ai_dev/n/n8d40b96205df
対象ファイル
| Provider | 主なファイル | 見る観点 |
|---|---|---|
| Firebase | firebase.json |
headers, redirects, rewrites
|
| Netlify |
netlify.toml, public/_headers
|
redirects, headers, backing store の制約 |
| Render | render.yaml |
routes, headers, 既存リソース優先 |
| Vercel | vercel.json |
rewrites, headers, preview deployments |
まず揃える挙動
-
/が期待通り返る - 深いパスに直接アクセスしても
index.htmlに戻る - 静的アセットが rewrite に巻き込まれない
- preview と production で挙動が変わっていない
- セキュリティヘッダーが同じ意図で返る
完全に同じ設定を書く必要はありません。
大事なのは、ユーザーから見た挙動と安全ヘッダーの意図を揃えることです。
rewrite / SPA fallback
SPA の静的配信では、深いパスに直接アクセスしたときに 404 になりがちです。
確認する順番は固定しておくと楽です。
-
/が返る -
/games/chessのような深いパスが返る - JS / CSS / 画像が rewrite されずに返る
- 存在しない静的ファイルの扱いを確認する
Provider ごとに rewrite の優先順位が違うため、「設定を書いた」ではなく「実際のレスポンスを見る」ことが重要です。
headers / CSP / HSTS
最低限、次を見ます。
Content-Security-PolicyStrict-Transport-SecurityX-Content-Type-OptionsReferrer-Policy
CSP hash を使っている場合は、最新ビルドの成果物と一致しているか確認します。
更新時の作業順
- ビルド成果物を作る
- CSP hash を必要に応じて再生成する
- Firebase / Netlify / Render / Vercel の設定差分を確認する
- preview で深いパスと静的アセットを確認する
- production 反映後に同じ確認をする
トラブル時の切り戻しメモ
- どの Provider で壊れたか
- rewrite か headers か
- preview だけか production でも起きるか
- 直前に触った設定ファイルは何か
- 切り戻し先として使える Provider はどれか
この粒度で残しておくと、複数ホスティング運用が「設定が増えるだけ」ではなく、障害時に戻れる運用になります。