プロキシポートとは？番号、プロトコル、そしてIANAの見解

まず最初に、私たちの立場を明言しておきます。私たちは Geonode であり、プロキシを販売しているため、「プロキシが機能しない」という問い合わせを数多く受け付けています。何よりもまず正直に申し上げると、ポート番号が問題であることはほぼありません。 私たちの経験上、原因の発生確率の高い順に挙げると、認証情報の誤り、更新し忘れたIP許可リスト、HTTPSリクエストにプレーンHTTPポートを使用していること、ターゲット側によるブロック、そして最後に、実際にポート番号が間違っている場合です。デバッグを行う際は、ポート番号をランダムに試すのではなく、このリストに沿って順に確認してください。後者の方法は生産的に感じられますが、実際にはほとんど効果がないのです。

とはいえ、その番号が何を意味するかを理解しておけば、失敗の原因分類全体が明確になります。

ポートとは実際何なのか

1台のマシンには1つのアドレスがあり、ネットワーク通信を行う可能性のあるプログラムが複数存在します。ポート番号は、オペレーティングシステムが、特定の接続がどのプログラムに属するかを判別するためのものです。

アドレスはパケットをそのマシンに届ける役割を果たします。ポートは、そのマシン上の適切なプロセスにパケットを届ける役割を果たします。1台のサーバーで、443番ポートでWebサーバーを、22番ポートでSSHデーモンを、8080番ポートでプロキシを同時に実行できるのは、各接続に宛先ポートが指定されており、それが適切なリスナーへとパケットをルーティングするためです。

特にプロキシの場合、ポートにはもう1つの役割があります。1台のプロキシサーバーは、しばしば複数のポートでリスニングしており、各ポートは異なる設定になっています。同じソフトウェア、同じマシンであっても、接続するポート番号によって動作が異なります。そのため、プロバイダは単一の値ではなくリストを提供するのです。この点については、後ほど改めて触れます。

3つのポート範囲

ポート番号は0から65535まであり、RFC 6335では、この範囲を3つの範囲に分割しています：

範囲	名称	番号	割り当て
システム	ウェルノウンポート	0–1023	IANA による割り当て
ユーザー	登録済みポート	1024–49151	IANA による割り当て
動的	プライベートポートまたは一時ポート	49152–65535	割り当てなし

実用上、2つの重要な点があります。

システムポートへのバインドには、通常、特権の昇格が必要です。 Unix系システムでは、1024未満のポートへのバインドには、従来からroot権限が必要です。これが、プロキシが80ではなく8080や3128に配置される直接的な理由です。低いポートを確保するためにrootとしてプロキシを実行するのは、見かけ上の利点を得るための割に合わない代償だからです。

動的ポートは、自身の接続元となるものです。 8080番ポートのプロキシに接続すると、お使いのマシンは上位の範囲から一時的な送信元ポートを選択します。これは、ファイアウォールのログを確認して、「なぜ自分のトラフィックがポート51423から発信されているように見えるのか」と不思議に思うまでは、気づかないものです。

一般的なプロキシポートと、IANAが実際に定めている内容

ここが、一般に広く信じられている通説と公式記録が食い違う点であり、この相違は示唆に富んでいます。以下の項目は、IANAサービス名およびトランスポートプロトコルポート番号レジストリから、公開されているCSVファイルを直接読み取ったものです。

ポート	一般に呼ばれている名称	IANAが実際に登録している内容
8080	デフォルトのプロキシポート	`http-alt` — 「HTTP Alternate (port 80を参照)」
3128	Squidポート	`ndl-aas` — 「Active API Server Port」
1080	SOCKS	`socks` — 「Socks」
8118	Privoxy	`privoxy` — 「Privoxy HTTP proxy」
8888	代替プロキシポート	`ddi-tcp-1` — 「NewsEDGE サーバー TCP (TCP 1)」
9050	Tor SOCKS	`versiera` — 「Versiera Agent Listener」
8081	セカンダリプロキシポート	`sunproxyadmin` — 「Sun Proxy Admin Service」

この表をもう一度よく読んでください。一般的な通念を覆す内容だからです。誰もが「プロキシポート」だと考えているポートのうち、実際にプロキシ関連のサービスに登録されているのは1080と8118だけです。

ポート3128 — 一般的にSquidのデフォルトとして説明され、実際Squidのデフォルトでもある — は、全く無関係なサービスに登録されています。至る所のプロキシツールで使用されているポート8888は、あるニュース製品に属しています。すべてのTorユーザーが知っているポート9050は、監視エージェントに登録されています。

ここから得られる教訓は、これらのツールに何か問題があるということではありません。レジストリには申請された割り当てが記録されており、広く導入されているソフトウェアの多くは単に都合の良い番号を選んだだけで、登録を通じてではなく、使用を通じて慣例となったのです。慣例と登録は異なるシステムであり、両者が矛盾する場合は、ソフトウェアは慣例に従います。

実用的な教訓は、ポート番号だけでは、何がリスニングしているかについて決定的な情報は得られないということです。プロキシはどのポートでも動作可能です。慣習的な番号が存在するのは、誰かがデフォルトを選ばなければならないからであり、その番号自体に意味があるからではありません。

ポートはプロトコルを決定しない

この分野で最もよくある概念上の誤解です。

ポート1080に接続したからといって、その接続がSOCKSになるわけではありません。 8080番ポートに接続したからといって、それがHTTPになるわけではありません。ポートは、どのリスナーが接続を受け取るかを決定するものであり、プロトコルは、そのリスナーが対応しているものです。両者が一致しない場合、接続はしばしば混乱を招く形で失敗します。つまり、役立つエラーメッセージが表示されるのではなく、タイムアウトが発生したり、接続がリセットされたり、判読不能なバイトが大量に送られてきたりするのです。

したがって、プロバイダからエンドポイントが提供された場合、必要な情報は3つあり、ポートはそのうちの1つに過ぎません：

ホスト
ポート
そのポートが対応するプロトコル — HTTP、HTTPS、SOCKS4、またはSOCKS5

クライアントの設定では、プロトコルを明示的に指定する必要があります。curl では、-x引数のスキームにプロトコルが指定されます：

curl -x http://proxy.example.com:8080 https://example.com
curl -x socks5://proxy.example.com:1080 https://example.com
curl -x socks5h://proxy.example.com:1080 https://example.com

この3つ目の形式は、最初の2つの違いよりも重要です。socks5hは、curlにホスト名をプロキシに送信して解決するよう指示します。一方、socks5はローカルで解決し、そのアドレスを送信します。その結果、DNSリークが発生します。つまり、トラフィックはプロキシを経由して送信される一方で、DNSクエリは自身のリゾルバーに送信されることになります。これはまさに、セッションがフラグ付けされる原因となるような不整合です。SOCKS5を、自分が別の場所にいるように見せることが重要な用途で使用している場合は、socks5hを使用してください。

HTTP、HTTPS、SOCKSにおける同一ポートの動作の違い

これら3つのケースには違いがあり、それが多くの混乱を招く現象の理由となっています。

HTTPプロキシを経由する通常のHTTP。 クライアントはリクエスト行に完全なURLを送信し、プロキシが代わりにそのページを取得します。プロキシはすべての情報を確認でき、変更することも可能です。

HTTPプロキシを経由するHTTPS。 クライアントは CONNECT というリクエストを発行し、プロキシがこれを許可する場合、TCPトンネルを開設して、内容を読み取ることなくバイトデータを中継します。これが、HTTPプロキシがHTTPSトラフィックを処理できる理由であり、同じポートで両方を処理できる理由でもあります。

これに伴い、2つの障害モードが生じます。一部のプロキシは、CONNECTを特定の宛先ポート（通常は443）に制限しているため、標準以外のポートへのHTTPSリクエストは拒否される一方で、通常のブラウジングは機能します。また、一部のポートはプレーンHTTP専用に設定されており、CONNECTが完全に無効化されている場合もあります。この場合、HTTPリクエストは機能するもののHTTPSリクエストは失敗するという現象が見られますが、これは証明書の問題のように見えますが、実際にはそうではありません。

SOCKS。 RFC 1928 では、SOCKS5がアプリケーション層の下で動作するプロトコルとして定義されています。SOCKSはHTTPを一切理解せず、TCP接続を中継するだけであるため、HTTPプロキシよりも汎用性が高いと言えます。 HTTPプロキシでは処理できないプロトコルに対応できますが、キャッシュやヘッダーの書き換えなど、HTTP固有の処理は一切行えません。

選択の目安として：ヘッダー処理が必要なWebトラフィックにはHTTPプロキシを、HTTP以外のものをプロキシする必要がある場合や、プロキシに可能な限り少ない情報しか知られたくない場合にはSOCKS5を選択してください。

プロバイダーが複数のポートを提供する理由

マルチポートのエンドポイントは初心者にとって分かりにくいものですが、その仕組みは単純です。プロバイダーは設定情報をポート番号にエンコードしているため、ユーザーが別の方法で設定情報を渡す必要がないようにしているのです。

一般的な仕組み：

ポートローテーション。 あるポートはリクエストごとに新しい出口アドレスを割り当て、別のポートは数分間のセッションの間、同じアドレスを維持します。認証情報もホストも同一ですが、ポートが異なります。

地理的ターゲティング。 ポートのブロックが国や地域に対応付けられています。

セッション識別。 各ポート番号が永続的なセッションに対応するポート範囲であり、同じポートに繰り返し接続することで、常に同じ出口アドレスが得られる。

**プロトコル。**あるポートはHTTPを、別のポートはSOCKS5を扱う。

一部のプロバイダーは、ポートを変更する代わりに、ユーザー名の構文を通じて同様の処理を行う。つまり、ポートを変えるのではなく、ユーザー名にパラメータを追加する。どちらのアプローチも存在し、どちらが優れているというわけではありません。購入したサービスのドキュメントを必ず確認する必要があります。なぜなら、推測に頼った場合の失敗モードは、意図した動作とは異なる結果をもたらしながらリクエストが成功してしまうことだからです。

この最後の点は強調する価値があります。ポートローテーション方式において、ポートを間違えても通常はエラーは発生しません。その結果、意図とは異なる動作をするリクエストが成立してしまいます。例えば、望んでいないセッションの永続化や、要求していない国への接続などが発生する可能性があります。これは、プロキシのテストが重要な理由で取り上げた「サイレント・フェイル」の一種であり、ポートの混同はその中でも特に一般的な原因の一つです。

トラブルシューティング：各エラーが示すこと

エラーの種類によって原因が異なるため、それらを正しく読み取れば、当て推量を大幅に減らすことができます。

症状	考えられる原因	確認事項
接続拒否（即時）	該当ポートでリスニングしているプロセスがない	ポート番号、ホスト
タイムアウト、応答なし	ファイアウォールがパケットを黙って破棄している	送信ルール、プロバイダのステータス
407 プロキシ認証が必要	認証情報が間違っているか、欠落している	ユーザー名、パスワード、IP許可リスト
プロキシ自体からの 403	認証は通ったが許可されていない	プランの制限、宛先制限
HTTP は動作するが、HTTPS は動作しない	そのポートで`CONNECT`

「接続拒否」と「タイムアウト」の違いは、最も有用でありながら最も見過ごされがちな点です。 「接続拒否」とは、応答があったものの拒否されたことを意味します — サーバーには到達可能ですが、そのポートでリスニングしているものがない状態です。「タイムアウト」とは、まったく応答がなかったことを意味します — 通常、ユーザー側、あるいはユーザーとプロキシ間のいずれかで、ファイアウォールがパケットをドロップしていることが原因です。前者はポート番号の誤りを示唆しますが、後者がその原因であることはほとんどありません。

簡単な特定テスト：

nc -zv proxy.example.com 8080

これで接続できれば、ポートは開いており到達可能です。残りの失敗は、ネットワークの問題ではなく、認証またはプロトコルの問題です。接続できない場合は、アプリケーションのデバッグを中止してください — 問題はアプリケーションの下流にあります。

また、407エラーについては特に言及する価値があります。これは最も一般的なエラーであり、初めて目にする人にとってはポートの問題のように見えるからです。しかし、そうではありません。これは、プロキシへの接続に成功したものの、プロキシが要求する認証情報を指定していないか、誤って指定したことを意味します。ポートは正しかったのです。

公開すべきではないポート

プロキシを購入するのではなく、独自にプロキシを運用している場合に該当します。

認証不要のプロキシをインターネットに公開してはいけません。 公開されたプロキシは数時間以内に発見されてしまいます（アドレス空間全体が継続的にスキャンされているため）。その結果、あなたが許可していないトラフィックが中継され、そのトラフィックはあなたのアドレスに帰属することになります。その結果、あなたのアドレスがブロックリストに登録されるだけでなく、さらに深刻な事態を招く恐れがあります。プロキシがインターネットからアクセス可能な場合は、認証が必要です。

可能な限り、送信元アドレスでアクセスを制限してください。 認証情報に加えてIPアドレスの許可リストを設定することは、認証情報のみの場合に比べて有意義な改善であり、コストもかかりません。

珍しいポート番号が保護になるとは考えないでください。 サービスをポート47281に移しても、隠れるわけではありません。単一のホストのポート範囲全体をスキャンするのに数秒しかかかりません。ここでは、目立たないことによる具体的なメリットは得られません。

CONNECTの宛先を制限してください。 任意のホストの任意のポートにCONNECTを行うプロキシは、汎用リレーとなります。これを443番ポートに限定し、実際に必要な宛先のみに制限することで、認証情報が漏洩した場合に悪用される可能性を大幅に低減できます。

ローカル環境のみで利用する場合は、localhostにバインドする。 同じマシン上のソフトウェアのみが使用するプロキシは、0.0.0.0ではなく、127.0.0.1でリスンすべきです。この1行の設定で、この種の問題をすべて防ぐことができますが、これはセルフホスト環境において最もよくあるミスです。

よくある質問

プロキシのデフォルトポートは何ですか？

普遍的なデフォルトは存在しません。HTTPプロキシでは8080、Squidのインストールでは3128、SOCKSでは1080が最も一般的な慣例となっています。これらはいずれも必須ではなく、プロキシは任意のポートでリスニング可能です。また、IANAのレジストリには、8080や3128がプロキシサービスとして登録されていません。必ずプロバイダが指定するポートを使用してください。

8080はプロキシポートですか？

慣例上は、よくそう扱われます。公式には、IANAは8080をhttp-altとして登録しており、その説明は「HTTP Alternate（ポート80を参照）」となっています。これは代替のWebサーバーポートであり、プロキシポートではありません。8080がプロキシの慣例となったのは、覚えやすく、バインドするのにroot権限を必要としないからであり、プロキシとしての意味を持つからではありません。

SOCKS5 はどのポートを使用しますか？

慣例上は 1080 です。これは、慣例と登録内容が一致する数少ない例の一つです。IANA は 1080 を socks として登録しています。個々の導入環境によって異なります。たとえば、Tor の SOCKS ポートのデフォルトは 9050 ですが、IANA はこのポートを全く関係のない用途として登録しています。

なぜプロキシはHTTPでは動作するのに、HTTPSでは動作しないのですか？

ほとんどの場合、そのポートがCONNECTメソッドを許可していないためです。これはHTTPSトラフィックをHTTPプロキシ経由でトンネル化する仕組みです。あるいは、CONNECTが特定の宛先ポートに制限されているためです。プロバイダがHTTPS用に別のポートを提供しているかどうかを確認し、接続先の宛先ポートが許可されているか確認してください。

使用するプロキシポートを確認するにはどうすればよいですか？

プロバイダのドキュメントを参照してください。ポート番号だけでは、どのサービスがリスニングしているかを確実に判断することはできません。どうしても確認する必要がある場合は、nc -zv host port を使用すると、何かがリスニングしているかどうかはわかりますが、どのプロトコルを使用しているかはわかりません。

プロキシポートとプロキシサーバーの違いは何ですか？

サーバーとは、トラフィックを処理するソフトウェアおよびマシンのことです。ポートとは、そのマシンにある番号が割り当てられた接続ポイントのうち、どのポートに接続するかを指します。 1台のサーバーは、異なる設定（ローテーションの動作、国、プロトコルなど）で複数のポートを常時リスニングしていることが多いため、プロバイダは1つの番号ではなくリストを提供します。

プロキシにはどのポートでも使用できますか？

技術的には、特別な権限がなければ1024～65535の範囲内のどのポートでも使用可能です。実際には、プロバイダーが割り当てるポートを使用することになります。これらはプロバイダー側の設定に対応しているからです。独自にプロキシを運用する場合は、49152以上の動的範囲は避けてください。オペレーティングシステムがその範囲から一時的な送信元ポートを割り当てるため、衝突が発生すると断続的な問題が生じ、その原因の特定が極めて困難になるからです。

ポート番号はプロキシの速度に影響しますか？

いいえ。ポートはアドレス指定の詳細に過ぎず、それ自体にパフォーマンス上の特性はありません。同じプロバイダーでもポートによってパフォーマンスが異なる場合、その原因はポート番号そのものではなく、異なるインフラを経由しているか、ローテーションの挙動が異なるためです。

まとめ

プロキシポートはルーティングの詳細に過ぎません。これは、宛先マシンに対して、どのリスニングプロセスが接続を処理すべきかを伝えるだけであり、それ以上の意味はありません。その番号自体に決定的な意味はありません。IANAレジストリを見れば明らかですが、3128はSquidに登録されておらず、8888はニュース製品に属し、9050は監視エージェントです。これらは使用によって確立された慣習であり、ソフトウェアはこうした慣習に従うものです。

何かがうまくいかない場合、これは何を意味するのでしょうか。数字を推測するのではなく、エラーメッセージを読み解くことです。「Connection refused」はポートが間違っていることを示しています。「タイムアウト」はファイアウォールが原因であることを示しています。「407」はポートは正しかったが、認証情報が正しくないことを意味します。プロトコルエラーは、HTTPを期待しているSOCKSリスナーに接続したか、その逆であることを意味します。それぞれの症状は異なるレイヤーを示しており、ポート番号を入れ替えることが有効なのは最初のケースのみです。

また、1つのエンドポイントに対して複数のポートが指定されている場合は、適当に1つを選ぶのではなく、ドキュメントを参照してください。そこでの失敗モードはエラーメッセージそのものではありません。それは、間違った国や間違ったセッション動作を黙って使用しながら機能してしまうリクエストであり、これははるかに大きな代償を伴う種類の誤りです。

プロキシポートとは？ 実践ガイド