curl socks5h と socks5：ホスト名を解決するのはどちらか

人々は socks5h を socks5 の親しみやすい綴りとみなし、どちらも同じ場所へ同じリクエストを送ると期待する。余分な文字が移すのは、むしろ DNS 問い合わせのほうだ。リゾルバとプロキシが別々のネットワークにある機械では、それが成功するリクエストと失敗するリクエストの差になる。

一文字、二つのリゾルバ

どの地点で宛先名がアドレスになるかは、スキームが決める。ローカル解決は、自分の機械に設定されたリゾルバを使う。リモート解決はホスト名を SOCKS リクエストの中に入れ、プロキシが自分のリゾルバと自分のネットワーク観でそれを引く。どちらの書式も同じポートの同じプロキシ宛先へ接続するのだから、違いは経路ではなくリクエスト本体にある。

スキームが暗号化や認証を変えることはない。動くのは DNS の経路だけだ。だからこの文字は見落としやすく、間違えると高くつく。

同じプロキシ、違うリクエスト

二つの呼び出しは一文字しか違わない。それ以外はすべて同じだ。

curl --proxy socks5://proxy.example:1080 https://service.example/
curl --proxy socks5h://proxy.example:1080 https://service.example/

The curl のプロキシのリファレンスはこれらのスキームを別々に記録しており、これを別名として扱わない決定的な理由になっている。許可された無害なエンドポイントに対して両方を実行し、違いを読んでほしい。リモートでの解決に成功しても、他のアプリケーションについては何も言えない。なぜなら ブラウザ、パッケージマネージャ、言語ランタイムはそれぞれ自分で選ぶからだ。

プロキシ自身の名前はローカルで解決される

そのコマンドでは、何よりも先に proxy.example がアドレスにならなければならず、その問い合わせは常にローカルだ。service.example の解決をプロキシへ移しても、プロキシ自身の名前には何の効果もない。その名前には、自分の機械から届くリゾルバが依然として必要だからだ。ここで VPN が構図を変える。

プロキシ名がトンネルの中でしか解決できないなら、接続は curl が始まる前にトンネルが上がっているかどうかにかかる。どちらのスキームが勝つかは、どちら側が答えられるかで決まる。自分の機械が宛先を解決できずプロキシができるときは socks5 が失敗し socks5h が成功する。自分の機械がトンネル経由で解決できプロキシができないときは socks5 が通り socks5h が失敗する。

スキームはプロキシへの接続を VPN の内側にも外側にも置かない。それを決めるのは経路表であり、スキームは経路表を一切見ない。だから同じ機械でも、一方のトンネルが一方のスキームを直し、もう一方を壊すことがある。文字が決めるのは、誰が問い合わせるかだけだ。

どちら側が何を解決できるか

公開プロキシは社内にしかない名前を解決できないので、ホスト名をそこへ送るとプロキシ側で失敗し、ローカルの DNS エラーではなくプロキシのエラーとして現れる。同じプライベートネットワークの内側にあるプロキシなら、そうした名前をたいてい解決でき、そこが socks5h の出番だ。リゾルバの位置は、本当に必要な方針から選ぶべきだ。リモート DNS が自動的に高機能なわけではなく、名前を第三者に渡すことでもある。公開の宛先ならどちらの書式でも動くので、他のツールがすでに使っているほうを選ぼう。

その選択はコメントではなく手順書に書き、資格情報は共有の履歴や診断出力に残さない。そのうえで一度に一つの変数だけを変える。同じ宛先、同じバイナリ、同じリゾルバ、一文字だけ。

どちらのバイナリが答えたか

同じ機械にある二つの curl バイナリは、バージョンもビルド機能も違いうる。Unix 系のシェルでは、type -a curl が経路上の一致をすべて並べ、curl --version が実際に走るほうの機能を示す。経路の前のほうにあるラッパースクリプトや別名は、結果がテストしているつもりのバイナリと合わないよくある原因だ。

サポートされないスキーム、名前を解決できないプロキシ、到達できない宛先は三つの別のエラーなので、文字を変える前にメッセージを読もう。socks5h の構文がないビルドはプロキシ文字列を未対応として報告するが、これは解決に失敗した名前とは同じではない。システムの curl についての古い報告を、あらゆるプラットフォームの恒久ルールにしてはいけない。