パスワード付きプロキシ（認証なし）：ローカルゲートウェイ

プロキシを購入し、login:password@host:portの形式の文字列を受け取ったが、プログラムは「アドレスとポート」だけを要求しています。おなじみの状況です：--proxy-serverフラグを持つChrome、WindowsやAndroidのシステム設定、古いパーサー、Seleniumグリッド、パスワードの入力フィールドがないユーティリティ。解決策は何年も同じです — ローカルゲートウェイ：あなたのマシン上にある小さなプロキシで、パスワードなしで接続を受け入れ、実際のプロキシに接続する際に自動的にログインを挿入します。4つの信頼できるツール、各ツールのコマンド、そして通常時間とお金を無駄にするエラーを見ていきましょう。

なぜプログラムはパスワード付きプロキシを「理解しない」のか

プロキシプロバイダーに認証する方法は2つあります：ログインとパスワードによる（Basic Auth）か、IPのホワイトリストによる。後者は問題を解決しますが、常に外部IPが必要です — 自宅のインターネットやモバイルネットワークではそれがないことが多く、クラウド機能では毎回起動時に変更されます。両方の方法については、プロキシ認証ガイドで詳しく比較しました。

ログインとパスワードの場合、プログラム自体の制限にぶつかります：

ChromeとChromium。 --proxy-serverフラグは、Chromiumのドキュメントによると、スキーム、ホスト、ポートを受け入れます（例：--proxy-server="foopy:8080"） — この構文には認証情報のフィールドがありません。通常のブラウザウィンドウではパスワードのダイアログが表示されますが、ヘッドレスモードや自動テストでは誰もそれを入力できません。
システム設定。 Windowsの手動プロキシ設定やほとんどのAndroidファームウェアのWi-Fi設定には、ホストとポートしかありません。パスワードは特定のアプリケーションに尋ねられるか、どこにも入力できません。
古い自作ソフト。 多くのユーティリティやライブラリはプロキシをサポートしていますが、認証なしで、またはパスワード内の特殊文字で壊れます。
プロキシを全くサポートしていないプログラム。 環境変数や設定を読み込まないコンソールユーティリティ。

ローカルゲートウェイはこれら4つのケースをすべて解決します：プログラムはパスワードなしでプロキシ127.0.0.1:8080を認識し、ゲートウェイはプロバイダーにログイン情報を付加してトラフィックを転送します。

スキームの動作

あなたのマシン（またはパーサーが動作しているVPS）で軽量プロキシサーバーが起動し、ローカルポートをリッスンします。例えば、127.0.0.1:8080です。
ゲートウェイの設定ファイルには「親」プロキシ（アップストリーム） — プロバイダーのアドレス、ログイン、パスワードが記載されています。
プログラムは認証なしでローカルポートに接続します。
ゲートウェイはプロバイダーへの接続を開き、認証を通過し、トラフィックをさらに転送します。ウェブサイトにとって、あなたは自分のIPアドレスではなく、プロバイダーのIPアドレスとして見えます。

この時、HTTPSは復号化されません：HTTPプロキシを介してブラウザはCONNECTメソッドでトンネルを確立し、ゲートウェイは暗号化されたバイトをそのまま転送します。

オプション1：gost — 一つのコマンド、設定なし

gost（GO Simple Tunnel）は、Windows、macOS、Linux用の単一の実行ファイルです。これはゲートウェイを立ち上げる最も迅速な方法です。gostのフラグ-Lはローカルサービスを指定し、-Fはトラフィックを転送するノードを指定します。認証情報はノードのアドレスに直接記載されます：

gost -L http://127.0.0.1:8080 -F socks5://LOGIN:PASSWORD@HOST:PORT

これで、任意のプログラムがパスワードなしでHTTPプロキシ127.0.0.1:8080を使用できます。パスワードに特殊文字（@、:、#）が含まれている場合、gostのドキュメントはそれをbase64でauthパラメータを通じて渡すことを提案しています：

echo -n LOGIN:PASSWORD | base64
gost -L http://127.0.0.1:8080 -F socks5://HOST:PORT?auth=<結果_base64>

注意：authが指定されている場合、アドレスに直接記載されたログインとパスワードはgostによって無視されます。複数の-Fフラグを連続して使用すると、複数のプロキシのチェーンが形成されます。

いつ使用するか：プロキシと「今すぐ」ブラウザまたはスクリプトを素早く「仲良く」させる必要がある場合、パッケージのインストールや設定の修正なしで。

オプション2：3proxy — 一台のマシンで多くのポート

3proxyは、1つのファイルに設定されたコンパクトなプロキシサーバーです。重要なディレクティブはparentです；その構文はドキュメントによると、parent <weight> <type> <ip> <port> <username> <password>であり、allowルールの後に記載する必要があります。ゲートウェイの最小設定は次の通りです：

auth iponly
allow * 127.0.0.1
parent 1000 http HOST PORT LOGIN PASSWORD
proxy -p8080 -i127.0.0.1

ここで重要な点は：

auth iponly — パスワードなしですが、ACLによる確認があります；ルールallow * 127.0.0.1はローカル接続のみを許可します。
重み1000は「常にこの親を通過する」ことを意味します。重みが1000未満の場合、3proxyはランダムなチェーンを構築するために使用します。
親のタイプ：http、connect、socks4、socks5など — プロバイダーが提供したプロトコルを使用してください。
-i127.0.0.1はサービスをローカルインターフェースにバインドします。デフォルトでは3proxyはすべてのインターフェースで接続を受け入れます。

便利なテクニック：異なるポートと異なるプロバイダーのアカウントで、allow / parent / proxyブロックを何度も繰り返すことです。これにより「ポート = 個別のプロキシ」が得られます：127.0.0.1:8081 — アメリカ、:8082 — ドイツ、など。この形式は、プロキシが「ホスト:ポート」のリストで入力されるソフトウェアを含むほとんどすべてのソフトウェアで理解されます。

いつ使用するか：数十のプロファイルやストリームがあり、それぞれに独自の出口が必要な場合。

オプション3：Squid — キャッシュとログが必要な場合

Squidは重いですが、キャッシュ、詳細なログ、および柔軟なACLを提供します。プロバイダーはcache_peerを介して親ノードとして記載され、ディレクティブnever_direct allow allはSquidが親をバイパスしてインターネットに直接アクセスすることを禁止します：

http_port 127.0.0.1:3128
cache_peer HOST parent PORT 0 no-query default login=LOGIN:PASSWORD
never_direct allow all

Squidのドキュメントからのニュアンス：

ICPポートは、親がそれをサポートしていない場合0を設定します — 商用プロキシにはありません。
login=にはURLエスケープシーケンス（例えば、スペースのための%20）が許可されているため、パスワード内の%は%%として記載する必要があります。
never_directなしでは、Squidはサイトに直接アクセスする方が有利だと判断する可能性があり、リクエストがあなたの実際のIPで送信されることになります。これは、パーシングやマルチアカウントにとって最悪のシナリオです。

いつ使用するか：オフィスやチームで、誰がどこに行ったかのログが必要な場合、または同じリソースへの繰り返しリクエストが必要な場合。

オプション4：proxychains-ng — プロキシサポートのないプログラム用

もしプログラムがプロキシを全くサポートしていない場合、proxychains-ng（LinuxおよびmacOS）が役立ちます。これはプログラムのネットワーク呼び出しをキャッチし、そのTCP接続をプロキシにラップします。SOCKS4a、SOCKS5、HTTPがサポートされ、認証はSOCKS用のログインとパスワード、HTTP用のBasicです。[ProxyList]セクションの行はタイプ ip ポート [ログインパスワード]の形式です：

strict_chain
proxy_dns
tcp_read_time_out 15000
tcp_connect_time_out 8000

[ProxyList]
http HOST PORT LOGIN PASSWORD

起動：proxychains4 curl https://api.ipify.org — レスポンスにはあなたのIPではなくプロバイダーのIPが表示されます。

strict_chain — リスト内のすべてのプロキシが順番に使用され、1つが利用できない場合は接続がありません。dynamic_chainよりも安全で、死んだノードをスキップします。
proxy_dns — DNSリクエストもプロキシを通じて送信されます。これがないと、あなたのインターネットプロバイダーはあなたがリクエストしているドメインを確認でき、ウェブサイトはDNSとIPのジオロケーションの不一致に気づく可能性があります。
設定は順番に検索されます：-fのファイルまたはPROXYCHAINS_CONF_FILE変数、次に./proxychains.conf、~/.proxychains/proxychains.conf、/etc/proxychains.conf。

制限：著者自身が述べているように、TCPのみ（UDPとICMPはプロキシされません）、多くのプロセスを生成するプログラムでの障害の可能性、macOSではSIP保護がシステムプログラムをキャッチすることを許可しません。

どのツールを選ぶべきか：短いメモ

1つのブラウザまたはスクリプト、今すぐ必要 — gost。
多くのプロファイル、各自に独自のIPまたは国 — 3proxyでアカウントごとに別々のポート。
チーム、リクエストのログ、キャッシュ — Squid。
プロキシ設定が全くないプログラム — proxychains-ng。

最も高くつく5つのエラー

ゲートウェイがすべてのインターフェースをリッスンしている。 VPSで-L http://:8080でgostを起動すると、あなたのギガバイトでインターネット全体にオープンプロキシが得られます。オープンプロキシスキャナーはすぐに見つけます。常に127.0.0.1を指定し、他のマシンがゲートウェイを使用する場合はファイアウォールでポートを閉じてください。ボットネットがパーサーのサーバー上のオープンポートをすぐに見つける方法については、CARBONATOワームの解析で説明しています。
ゲートウェイをバイパスする漏洩。 never_directなしのSquid、proxy_dnsなしのproxychains、WebRTC/UDPを直接使用するブラウザ — これらはすべて実際のIPを暴露します。IP判定サービスやDNS漏洩テストで結果を確認してください。
すべてのアカウントに1つのゲートウェイ。 30のアンチデテクトプロファイルが1つのポートを同じスティッキーセッションで見ると、すべてが同じIPになります — これはアカウントの束縛への直接的な道です。プロファイルをポートごとに分けるか、プロバイダーのセッションパラメータを使用してください。
パスワード内の特殊文字。 @や:はlogin:pass@host形式のアドレス解析を壊します。gostではbase64パラメータを使用し、Squidではエスケープを使用するか、特殊文字なしのパスワードを生成してください。
ゲートウェイは余分なホップと障害点。 ローカルマシンでは遅延はほぼゼロですが、ゲートウェイが別のデータセンターにある場合、各リクエストにネットワーク遅延が追加されます。ゲートウェイをプログラムの近くに保ち、自動起動を設定してください（systemd、Windowsサービス）、さもなくばサーバーの再起動後にパーサーが静かにどこかに行ってしまいます。

ゲートウェイの背後にどのプロキシを設定するか

ゲートウェイは、背後にどのタイプのプロキシがあるかは気にしません — 選択はタスクによります：

レジデンシャルプロキシ — 保護されたサイト、マーケットプレイス、アンチデテクトプロファイルのパーシング用：家庭ユーザーのIPはアンチボットに対して疑念を引き起こしにくいです。
モバイルプロキシ — ソーシャルネットワークやアプリ用、チェックが最も厳しい場所：モバイルオペレーターの1つのIP（CGNAT経由）から通常多くの実際の加入者がネットワークに出ており、それをブロックすることはプラットフォームにとってリスクがあります。
データセンタープロキシ — 厳しい保護なしの大規模なタスク用：可用性のチェック、API、テスト。ギガバイトあたりのコストが最も安いです。

ローテーション付きプロキシの場合、IPの切り替えロジックは通常プロバイダーによって設定されます — ログインのパラメータやアカウントの設定を通じて。ゲートウェイはそれを壊しません：ログインをそのまま転送します。したがって、異なるセッションパラメータで複数のポートを立ち上げるのが便利です — 各リクエストごとに新しいIPを持つもの、30分間固定IPを持つものなど。

結論

ログインとパスワード付きのプロキシは、ローカルゲートウェイを介して任意のプログラムに適しています。gostは一つのコマンドで問題を解決し、3proxyは「ポート = プロファイル」に便利で、Squidはログが必要なチーム向け、proxychains-ngはプロキシについて何も知らないソフトウェアをプロキシに接続します。主なルールは：127.0.0.1のみをリッスンし、親をバイパスする直接接続を禁止し、ウェブサイトがあなたのIPではなくプロバイダーのIPを見ていることを確認することです。