プロキシサーバー設定

1. セットアップスクリプト（PACファイル）の正体

設定画面にある「スクリプトのアドレス」には、通常 .pac という拡張子のファイルのURLを入力します。この中身はJavaScriptで書かれた小さなプログラムです。

なぜ「手動設定」ではなく「スクリプト」なのか？

手動設定でプロキシサーバーのIPアドレスを直接入れると、すべての通信がそのプロキシを通ろうとします。しかし、これでは不都合な場合があります。

• 社内サイトは直接見たい: 社内の掲示板などにアクセスするのに、わざわざ外のプロキシを経由すると遅くなります。
• 特定のサイトだけプロキシを通したい: セキュリティ上の理由で、特定のクラウドサービス（SnowflakeやAWSなど）にだけ専用プロキシを通したい場合があります。
• プロキシが複数ある: メインのプロキシが混んでいる時にサブに切り替える、といった複雑な動きをさせたい場合です。

2. スクリプトがやっていること（イメージ）

スクリプトは、あなたがブラウザでURLを叩くたびに、裏側で以下のような判断を瞬時に行っています。

「今から google.com に行くの？ じゃあ プロキシA を使ってね」 「次は社内の internal.portal？ それは プロキシを通さず直接（DIRECT） つないで」 「もし プロキシA が壊れていたら、代わりに プロキシB を使って」

3. なぜ会社ではこれを使うのか？

管理者の視点では、以下のようなメリットがあります。

• 一括管理ができる: プロキシサーバーの住所が変わっても、管理者がサーバー上のスクリプトを1箇所書き換えるだけで、全社員の設定が自動で更新されます。
• 負荷分散: 通信の種類によってプロキシを使い分けることで、ネットワークの渋滞を防げます。
• SSLインスペクションの制御: 前にお話しした「SSLインスペクション」を、特定のドメインだけ避ける（Bypassさせる）といった細かい指示も、このスクリプトに書き込むことができます。

プロキシ設定の優先順位（ヒエラルキー）

基本的には以下の順番で適用されます。「より局所的で具体的な設定」が「広域的な設定」を上書きするというルールです。

1. コマンドライン引数（最強） snow --proxy ... や dbt run --proxy ... など、コマンド実行時に直接渡す設定。
2. ツール固有の環境変数 SNOWFLAKE_PROXY など、特定のツールだけが読み込む変数。
3. ツール固有の構成ファイル config.toml (Snowflake CLI) や profiles.yml (dbt) 内に記述された設定。
4. 標準の環境変数 HTTPS_PROXY, HTTP_PROXY, NO_PROXY など。PythonのRequestsライブラリなどはここを自動で見に行きます。
5. OS / システム設定（最弱） Windowsの設定画面やPACファイル。多くのCUIツール（CLIやPython）はここを無視することが多いため、環境変数での設定が必要になります。

SSLインスペクション時の通信フロー（接続確立まで）

1. PC → プロキシサーバー 「Snowflakeに繋ぎたい」とリクエストを送る。
2. プロキシサーバー → PC プロキシがSnowflakeのふりをして、**「プロキシが作った偽の証明書」**をPCに送りつける。
3. PC内部（ここが重要！） PC（Pythonやdbt）が、受け取った証明書をチェックする。
   • ここでルート証明書を確認: 「この証明書を発行したのは誰だ？…あ、設定されているルート証明書（社内CA）と一致した！信じてよし！」と判断。
   • ※ここで一致しないとエラーで終了します。
4. PC → プロキシサーバー 「証明書を確認した。暗号化通信を始めよう」と合意（ハンドシェイク完了）。
5. プロキシサーバー → Snowflake プロキシが今度は「PCのふり」をして、Snowflakeと本物の暗号化通信を確立する。
6. Snowflake → プロキシサーバー → PC データが流れる。
   • プロキシはSnowflakeからのデータを一度復号（中身を検査）し、再度「手順2の証明書」を使って暗号化してPCへ送る。

通信の「中継」で何が起きたか

プロキシサーバーは、あなたのPCの「身代わり」としてSnowflakeに接続しに行きます。

1. プロキシ → Snowflake: 「このPCの代わりに接続させてくれ」
2. Snowflake → プロキシ: 「いいよ、これが私の**身分証明書（us-west-2の証明書）**だ」
3. プロキシ内部: ここでプロキシがパニックを起こします。
   • プロキシの心の声：「あれ？PCからは『東京（ap-northeast-1）』に行きたいって言われたのに、このサーバーが出してきた証明書は『アメリカ（us-west-2）』って書いてあるぞ！？」
   • プロキシの判断：「これは偽物だ！PCに渡す前に、ここで通信を叩き切って守ってあげよう！」

これが、あなたが引用してくれたログにある Blocked by SSL_HOST_MISMATCH の瞬間の正体です。

---

データの復号（インスペクション）との関係

あなたが挙げてくれた「データが流れる（復号する）」ステップは、本来はこの「証明書の確認」が無事に終わった後に続くはずのステップでした。

• 正常な（インスペクションなしの）場合: プロキシは何も考えず、Snowflakeから届いた証明書をそのままPCにパスします。PC側で「Snowflakeはこういう仕様だ」と設定（ルート証明書など）されていれば、そのままデータ通信が始まります。
• 今回のエラーの場合: プロキシが「良かれと思って」中身をチェックしようとした（＝インスペクションしようとした）ために、ホスト名の不一致を検知してしまい、データが流れる前の段階で通信を自爆させてしまったのです。

ブログに書く際のポイント

「データの復号」という言葉を使うなら、このように整理すると非常に分かりやすくなります。

「インスペクション（復号）をしようとしたからこそ、エラーになった」

プロキシが中身を見ようとしなければ、単に「右から左へ」パケットを流すだけで済みました。 しかし、プロキシが「安全のために一度封筒を開けて（復号して）、中身の証明書が宛先と合っているか確認しよう」とした結果、Snowflake特有の仕様（東京なのにアメリカの証明書）に驚いて、封筒を破り捨ててしまった……。これが今回のトラブルの全貌です。