すべてのプロキシ接続には、使用が許可されていることを証明する手段が必要です。標準的なアプローチは2つあります。IPアドレスを登録して認証情報を省略する方法と、リクエストごとにプロキシサーバーのログイン・ユーザー名・パスワードで認証する方法です。
IP認証のみの方式は、アドレスが変わらない場合に最適です。しかし、自宅の回線、ネットワーク間を移動するノートパソコン、動的IPのVPSなど、アドレスが変わる可能性がある環境では、IPの変更に左右されない認証方法が必要です。そこでログイン／パスワード認証の出番です。
認証情報ベースの認証の仕組み
ソフトウェアがプロキシに接続すると、プロキシはアクセス権の確認を求めます。HTTPプロキシ認証では、クライアントはBase64でエンコードされたユーザー名とパスワードを含むProxy-Authorizationヘッダーを送信します。プロキシは認証情報を確認し、一致すれば通信が開始されます。curlを使った簡単な例をご覧ください： curl -x http://username:password@proxy-address:port https://example.com — またはPython requestsの場合： requests.get("https://example.com", proxies={"https": "http://username:password@proxy-address:port"}).
SOCKS5プロキシのユーザー名・パスワード認証では、プロセスが若干異なります。SOCKS5は独自のハンドシェイク中に認証情報を処理します。これはウェブトラフィックが開始される前の別のステップです。クライアントが認証を希望することを通知し、ログインとパスワードを送信すると、プロキシが成功または失敗を返します。実際の接続が開始されるのは、その後になります。
どちらの方法も目的は同じです。接続元のIPアドレスに関係なく、そのプロキシの使用が許可されていることを証明します。
IPのみではなく認証情報を使う理由
IPのみモードはよりシンプルです。シークレットも不要で、ソフトウェア側の設定もありません。ただし、静的パブリックアドレスが必要です。ISPがIPをローテーションした瞬間、ホワイトリストを更新するまでアクセスが途切れます。
ログイン／パスワード認証を使えば、ネットワーク環境への依存がなくなります。オフィス、カフェ、海外など、どこからでもプロキシに接続可能です。認証情報が正しく、IPアドレスが登録済みアドレスの/21サブネット内に収まっていれば、接続は確立されます。多くのプロキシプロバイダーは認証を単一のホワイトリストIPまたは/32の狭いレンジに制限していますが、FineProxyの/21サブネット方式は2,048アドレスをカバーするため、動的なIPローテーションによってセッションが切断されることはほとんどなく、市場では稀な高い柔軟性を実現しています。
以下のようなケースで重要になります：
- Wi-Fiネットワーク間を移動するノートPCやデバイス
- ISPが毎日新しいアドレスを割り当てる自宅回線
- 複数のメンバーが異なるロケーションから接続するチーム
- IPが変動するクラウドインスタンス上で実行されるCI/CDパイプライン
FineProxyでの仕組み
当社のプラットフォームではIP登録が必須です。これはシステムがお客様を識別するための基盤となります。ログイン／パスワード認証を追加すると、プロキシは登録されたアドレスの/21サブネット内の任意のIPからの接続を受け付けます。
これは2,048個のアドレスに相当します。ほとんどのISPは動的IPをはるかに狭い範囲内でローテーションするため、実際には手動で更新しなくても接続は維持されます。
FineProxyでは、HTTP、HTTPS、SOCKS5など当社が提供するすべてのプロトコルで認証情報をご利用いただけます。HTTPSの場合、各IPに固有のSSL証明書が割り当てられているため、クライアントとプロキシ間の暗号化接続は認証情報ベースの認証でも安全に保たれます。
認証情報はご購入後すぐにダッシュボードで確認できます。形式はシンプルで、HTTP/HTTPS の場合は username:password@proxy-address:port、SOCKS5 の場合はクライアントの認証設定で構成します。
購入後すぐにダッシュボードへ認証情報が表示されます。形式はusername:password@address:portで、ブラウザ・スクリプト・自動化ツールにそのまま貼り付けてご利用いただけます。
認証情報の安全な管理
ログイン／パスワード認証のデメリットは、認証情報が存在するということです。存在するものは漏洩する可能性があります。いくつかの実践的なルールをご紹介します：
認証情報をスクリプトにハードコーディングするのではなく、環境変数をご利用ください。export HTTPS_PROXY=”http://user:pass@proxy:port” とすれば、パスワードをソースコードから分離できます。
プロキシの認証情報をGitリポジトリにコミットしないでください。プライベートリポジトリであっても、共有、クローン、バックアップを通じて管理外の場所に流出する可能性があります。
お使いのツールが対応している場合は、設定ファイルに認証情報を保存するのではなく、実行時にシークレットマネージャーから取得することをおすすめします。