0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@hya2026

【AWS】DNS 切り替え前の動作確認、hosts を書き換えずに Chrome だけでできる

0
Last updated at Posted at 2026-10-23

TL;DR
AWS 移行や DNS 切り替えの前に「本番と同じドメインで AWS の検証環境を確認したい」とき、hosts ファイルは不要です。
Chrome を次のように起動するだけで、ALB や CloudFront の DNS 名をそのまま接続先にできます。IP が変わっても自動で追従します。

chrome.exe --user-data-dir="%LOCALAPPDATA%\chrome-verify-profile" --host-resolver-rules="MAP www.example.com my-alb-1234567890.ap-northeast-1.elb.amazonaws.com"

左はいつものブラウザで本番、右は bat から起動して同じ URL で AWS の検証環境が開く様子
左：いつものブラウザ（本番）／右：bat から起動した Chrome（AWS 検証環境）。URL は同じで、行き先だけが違います。

はじめに：AWS の検証で hosts がつらい問題

オンプレや別クラウドから AWS へ移行するとき、あるいは AWS 上で環境をリプレースするとき、Route 53 などの DNS を切り替える前に、本番と同じドメインで新環境を確認したい 場面があります。

昔ながらのやり方は hosts ファイルの書き換えですが、AWS が相手だとこんなことになりがちです。

  • ALB の IP を hosts に書いたら、翌日 IP が変わって繋がらなくなった
  • CloudFront の IP を調べたら、引くたびに違う IP が返ってきてどれを書けばいいかわからない
  • hosts を編集するたびに 管理者権限 でメモ帳を開き直す
  • 検証が終わったのに 戻し忘れて、本番を見ているつもりで AWS を見ていた
  • 現行本番と AWS 新環境を 並べて見比べたい のに、PC 全体が切り替わるのでできない

ひとつでも当てはまったら、この記事の方法で解決できます :raised_hands:

なぜ AWS だと hosts と相性が悪いのか

リソース IP の性質 hosts に IP を書くと…
ALB 負荷に応じてノードが増減し、IP が変わる ある日突然繋がらなくなる
CloudFront アクセス元に近いエッジの IP が返り、大量にある 1 つ固定しても本来の挙動と違う
NLB AZ ごとに IP は固定 動くが、DNS 名で管理する方が楽

AWS は「IP ではなく DNS 名で使ってね」という設計です。だったら検証も DNS 名のまま向ければいい、というのがこの記事のアイデアです。

この記事でできること

hosts 書き換え この記事の方法
接続先の指定 IP アドレス ALB / CloudFront の DNS 名
ALB の IP 変更 書き直しが必要 自動で追従
管理者権限 必要 不要
影響範囲 PC 全体 検証用 Chrome のウィンドウだけ
現行本番と並べて比較 できない できる
戻し忘れ事故 起きる 閉じるだけで終わり

こんなキーワードで探していた方にも役立つはずです。

  • AWS 移行 DNS 切り替え前 動作確認
  • ALB hosts IP 変わる / ALB 固定 IP なしで検証
  • CloudFront hosts 指定 / 代替ドメイン名 事前確認
  • Route 53 切り替え前 本番ドメインで確認
  • hosts 書き換えずに 検証環境 / Chrome host-resolver-rules

仕組み：Chrome の --host-resolver-rules

Chrome には、名前解決の直前にホスト名を置き換える起動オプション --host-resolver-rules があります。Chromium の開発者向けドキュメントにも記載されている機能です1。

--host-resolver-rules="MAP 本番ドメイン 置き換え先"

置き換え先には IP アドレスだけでなく、別のホスト名も指定できます。つまり ALB や CloudFront の DNS 名をそのまま書けます。

置き換えているのは「どの名前で DNS を引くか」だけです。URL・Host ヘッダー・SNI は本番ドメインのまま送られるので、

  • ALB のリスナールール（ホストヘッダー条件）
  • CloudFront の代替ドメイン名（CNAME）とビヘイビア
  • ACM の証明書

が DNS 切り替え後とまったく同じ条件で動作します。切り替え前のリハーサルにぴったりです。

なぜ IP が変わっても大丈夫なのか
hosts は「書いた瞬間の IP」で固定されます。一方この方法は「名前の置き換えルール」を持っているだけなので、アクセスのたびに DNS で その時点の ALB の IP を引き直します。

やってみる

まずは 1 行で試す

コマンドプロンプトで次を実行します（ドメインと ALB 名は自分の環境に置き換えてください）。ALB の DNS 名は、マネジメントコンソールの EC2 → ロードバランサー → 詳細の「DNS 名」からコピーできます。

"C:\Program Files\Google\Chrome\Application\chrome.exe" --user-data-dir="%LOCALAPPDATA%\chrome-verify-profile" --host-resolver-rules="MAP www.example.com my-alb-1234567890.ap-northeast-1.elb.amazonaws.com"

--user-data-dir は必須です
Chrome がすでに起動していると、オプションは黙って無視され、既存のウィンドウが開くだけになります。別プロファイルを指定することで、

  • 普段の Chrome が起動中でも確実にオプションが効く
  • 普段の Chrome（現行本番）と検証用 Chrome（AWS）を 同時に開いて見比べられる
  • Cookie やキャッシュが本番と混ざらない

というメリットがあります。

実戦版：複数ドメインをまとめて向ける bat

「静的サイトは CloudFront、アプリと API は ALB」のように、複数ドメインを AWS の複数リソースに振り分けている構成でも、bat にまとめればダブルクリック 1 回です。

chrome-verify.bat
@echo off
rem ============================================================
rem  AWS 検証環境確認用 Chrome 起動バッチ
rem  本番と同じ URL のまま、AWS の CloudFront / ALB に接続する
rem  ※ このファイルは Shift_JIS（ANSI）で保存すること
rem ============================================================
setlocal

rem ----- AWS のエンドポイント（環境を作り直したらここだけ直す） -----
rem  CloudFront ディストリビューションのドメイン名
set "CF=dxxxxxxxxxxxxx.cloudfront.net"
rem  ALB の DNS 名
set "ALB=my-alb-1234567890.ap-northeast-1.elb.amazonaws.com"

rem ----- Chrome を探す（よくある 3 か所） -----
set "CHROME="
if exist "%ProgramFiles%\Google\Chrome\Application\chrome.exe" set "CHROME=%ProgramFiles%\Google\Chrome\Application\chrome.exe"
if not defined CHROME if exist "%ProgramFiles(x86)%\Google\Chrome\Application\chrome.exe" set "CHROME=%ProgramFiles(x86)%\Google\Chrome\Application\chrome.exe"
if not defined CHROME if exist "%LOCALAPPDATA%\Google\Chrome\Application\chrome.exe" set "CHROME=%LOCALAPPDATA%\Google\Chrome\Application\chrome.exe"
if not defined CHROME (
  echo [ERROR] chrome.exe not found. Check chrome://version
  pause
  exit /b 1
)

rem ----- 検証用プロファイル（消せばキャッシュ等をリセットできる） -----
set "PROFILE=%LOCALAPPDATA%\chrome-verify-profile"

rem ----- 対象ドメイン（書式：MAP 本番ドメイン AWSの接続先） -----
rem  静的サイト → CloudFront
set "R=MAP www.example.com %CF%"
set "R=%R%, MAP example.com %CF%"
rem  アプリ / API → ALB
set "R=%R%, MAP app.example.com %ALB%"
set "R=%R%, MAP api.example.com %ALB%"

echo [AWS VERIFY MODE] %R%
start "" "%CHROME%" --user-data-dir="%PROFILE%" --host-resolver-rules="%R%" https://www.example.com/

endlocal
:bulb: bat の書き方のポイント
  • エンドポイントを変数（CF / ALB）にしておけば、CloudFormation や Terraform で環境を作り直して DNS 名が変わっても、1 か所の修正で済みます
  • set "R=%R%, MAP ..." で 1 行ずつルールを足す形にすると、追加・削除・コメントアウトが楽です
  • 別のドメイン（example.jp など）や、HTTP を NLB で受けている構成も、同じ書式で MAP を足すだけです
  • 日本語コメントを入れる場合は Shift_JIS（ANSI）で保存 してください。UTF-8 で保存すると文字化けしたり、まれに誤動作したりします
  • 最後の URL は起動時に開くページです。不要なら消して OK

本当に AWS に繋がっている？の確認方法

見た目が現行本番と同じだと不安になりますよね。確認は DevTools で一発です。

  1. 検証用 Chrome で F12 → Network タブ
  2. ページを再読み込み
  3. リクエストを選んで Headers → General → Remote Address を見る

ここに表示された IP が、ALB の DNS 名を引いた結果と一致すれば OK です。

# WSL や Mac のターミナルで
dig +short my-alb-1234567890.ap-northeast-1.elb.amazonaws.com

# PowerShell なら
Resolve-DnsName my-alb-1234567890.ap-northeast-1.elb.amazonaws.com

CloudFront の場合は、レスポンスヘッダーに x-cache や x-amz-cf-pop が付いていれば CloudFront 経由です。

「サポートされていないコマンドライン フラグ」の警告が出るけど？

起動すると、上部にこんな警告バーが出ます。

サポートされていないコマンドライン フラグ --host-resolver-rules=... を使用しています。これにより、安定性とセキュリティに問題が生じます。

エラーではなく、ただの警告です。 そのまま使えます。

--host-resolver-rules は「このドメインへの通信を別の場所に向ける」オプションです。もしマルウェアが同じことをすれば、銀行のドメインのまま偽サーバーに誘導できてしまいます。そのため Chrome は、こうした「危険になり得るフラグ」が付いているときに必ず警告を出す作りになっています。

あえて消さないのがおすすめ
ポリシー（CommandLineFlagSecurityWarningsEnabled）で非表示にもできますが、PC 上のすべての Chrome に効いてしまいます。
それよりも、この警告バーを 「今このウィンドウは AWS 新環境を見ている」目印 として使うのがおすすめです。現行本番と並べて開いているとき、取り違え防止にちょうどいいんです :eyes:

AWS 構成別ハマりポイント集

:x: ALB で 503 / 想定外のページが返る

ALB のリスナールールが ホストヘッダー条件 で振り分けている場合、本番ドメイン用のルールが登録されているか確認してください。この方法では Host ヘッダーが本番ドメインのまま届くので、ルールが無いとデフォルトアクションに落ちます。

:x: ALB で証明書エラーになる

ALB の HTTPS リスナーに、本番ドメインをカバーする ACM 証明書が必要です。複数ドメインある場合は、リスナーに証明書を追加すれば SNI で使い分けられます。

:x: CloudFront で 403 / 証明書エラーになる

CloudFront は Host ヘッダーでディストリビューションを判別します。検証用ディストリビューションの 代替ドメイン名（CNAME） に本番ドメインが登録されていて、us-east-1 の ACM 証明書が設定されている必要があります。

なお、同じ代替ドメイン名は原則として複数のディストリビューションに同時登録できません。現行本番も CloudFront を使っている場合は注意してください。

:x: Web サーバーのエラーページ（403 / 404 など）が出る

Apache や Nginx などのエラーページが表示されている場合、ALB を通って EC2 などのバックエンドまで届いています。Chrome やこの方法の問題ではなく、サーバー側の設定の問題です。Web サーバーのエラーログを見ると原因がわかります。

よくある原因は、Web サーバー側の IP 制限、ファイルの権限、ファイルの配置漏れなどです。

:x: タイムアウトする

セキュリティグループで、自分の接続元 IP（社内のグローバル IP など）からの 80 / 443 が許可されているか確認してください。検証期間中は接続元を絞っているケースが多いです。

:x: 画面の一部（画像など）だけ現行本番のものが出る

ページ内で、ルールに書いていない別ドメイン（画像用 CDN、S3 の静的ファイル、API 用サブドメインなど）を読み込んでいる可能性があります。DevTools の Network タブでドメインを確認し、MAP を追加してください。

:x: 長時間使っていたら急に繋がらなくなった

ALB の IP が変わった直後かもしれません。Chrome は名前解決の結果を短時間キャッシュするので、少し待ってから再読み込みすれば新しい IP に追従します。

:x: Chrome が見つからない / オプションが効かない

Chrome のインストール先は環境によって違います。普段の Chrome で chrome://version を開き、「実行ファイルのパス」を bat の CHROME に直接書いてください。

オプションが効かず現行本番に繋がる場合は、--user-data-dir を付け忘れていないか確認してください。

おまけ 1：Route 53 のレコードも切り替え前に確認する

画面の確認ができたら、DNS 切り替えの直前に Route 53 のホストゾーンに正しいレコードが入っているか も確認しておくと安心です。ネームサーバーを切り替える前でも、Route 53 のネームサーバーに直接問い合わせれば確認できます。

# ホストゾーンの NS レコードに書かれているネームサーバーを指定
dig @ns-123.awsdns-45.com www.example.com
dig @ns-123.awsdns-45.com api.example.com

ALB / CloudFront へのレコードは、CNAME ではなく エイリアスレコード で作るのがおすすめです。ゾーンの頂点（example.com）にも設定でき、Route 53 が IP を直接返してくれます。

おまけ 2：Mac / Linux / curl でも同じことができる

Mac

open -na "Google Chrome" --args \
  --user-data-dir="$HOME/chrome-verify-profile" \
  --host-resolver-rules="MAP www.example.com my-alb-1234567890.ap-northeast-1.elb.amazonaws.com"

Linux

google-chrome \
  --user-data-dir="$HOME/chrome-verify-profile" \
  --host-resolver-rules="MAP www.example.com my-alb-1234567890.ap-northeast-1.elb.amazonaws.com"

curl

curl の --connect-to を使うと、同じように「名前はそのまま、接続先だけ ALB に向ける」ができます。ヘルスチェック用 URL の疎通確認などに便利です。

curl -I https://www.example.com/ \
  --connect-to www.example.com:443:my-alb-1234567890.ap-northeast-1.elb.amazonaws.com:443

curl --resolve も有名ですが、こちらは IP アドレスしか指定できません。IP が変わる ALB には --connect-to が便利です。

ほかの方法との比較

方法 手軽さ 影響範囲 ALB の IP 変更 現行本番と並べて比較
hosts 書き換え ○ PC 全体 × ×
hosts を自動更新するスクリプト △ PC 全体 △（実行時のみ） ×
プロキシ（Squid など）経由 × 設定したアプリ ○ ○
Chrome --host-resolver-rules ◎ そのウィンドウだけ ◎ ◎

「AWS 新環境をブラウザで確認したい」という用途なら、--host-resolver-rules がいちばん手軽で安全です。

まとめ

  • AWS の DNS 切り替え前の確認に、hosts ファイルは不要
  • 接続先に ALB や CloudFront の DNS 名 をそのまま書けるので、IP が変わっても自動で追従
  • Host ヘッダー・SNI は本番ドメインのままなので、リスナールール・代替ドメイン名・ACM 証明書まで本番同様に検証できる
  • --user-data-dir で別プロファイルにすれば、現行本番と AWS 新環境を並べて見比べられる
  • bat にしておけば、移行プロジェクトのメンバー全員がダブルクリックで使える

「hosts の戻し忘れで、本番だと思ったら AWS だった」事故とは、これでお別れしましょう :wave:

参考

  1. Chromium のドキュメントでは、ホスト名を別のホスト名・IP アドレス・NOTFOUND エラーに置き換えられると説明されています。 ↩

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?