サーバーと地域の選定から、基本的なセキュリティ、プロキシの導入、認証とポート、クライアント接続、確認、接続できない場合の切り分け順序までを解説します。
サーバーと地域を選ぶ
プロキシ自体はCPUやメモリをほとんど消費しないため、サーバー選定でそこを最優先にする必要はありません。
最初から高性能なプランを選ぶ必要もありません。固定帯域と月間通信量がセットになった軽量アプリケーションサーバーのようなプランは、1つまたは少数のアカウントで自分用のプロキシを運用する程度なら通常は十分で、料金も低めです。複数インスタンスが必要な場合や帯域に明確な要件がある場合にのみ、リソースを個別に選べる汎用インスタンスを検討すればよいでしょう。
スペックより重要なのが地域です。出口IPはノードを配置した場所に属するからです。考え方は単純で、アカウントが対象とする市場と同じ場所にノードを置きます。アクセス速度だけで選ぶ人も多く、中国本土からは香港ノードが速い場合があります。しかし、アカウント情報が米国なのに出口がアジアにあるなら、その不一致のほうが速度より重要です。速度は二次的な指標で、整合性を優先します。
帯域は実際の用途から見積もります。管理画面の確認や日常的な運用だけなら小さな帯域で十分です。画像や動画を扱う操作があるなら増やし、同時にオンラインになるアカウントが多いほど必要な帯域も増えます。判断できない場合は最小プランから始め、1か月利用量を見て調整します。
起動後に先に済ませること
OSイメージはLinuxを選びます。一般的なディストリビューションにはSSHが標準で入っているため、別途リモート接続サービスを用意する必要はありません。購入時のログイン方式は、鍵ファイルよりカスタムパスワードにしておくと、後でプロキシを設定するときの変換作業を1段階減らせます。
サーバーを受け取ったら、まず4項目を控えます。パブリックIP、ユーザー名（Linuxでは通常root）、パスワード、SSHポート（通常22）です。これらがクライアント側に入力する情報になります。
次に基本的なセキュリティを設定します。標準の22番ポートを変更すると、自動スキャンの多くを避けやすくなります。事業者が鍵認証に対応している場合は設定後にパスワードログインを無効化できます。セキュリティグループとOSのファイアウォールでは、本当に必要なポートだけを許可し、それ以外は閉じます。数分の作業で、継続的なスキャンや認証情報を使った攻撃のノイズを減らせます。
プロキシサービスの2つの方法
1つ目はSSHトンネルを直接使う方法です。サーバーに追加のソフトを入れる必要はなく、クライアントがサーバー既存のSSHサービスを使って転送します。ポート22とサーバーのアカウント情報をそのまま使います。欠点は性能が平均的なことで、長時間の運用や同時接続が多い場合は負荷が高くなります。短期利用や少数アカウントに向いています。
2つ目は専用のプロキシサービスをサーバーにインストールする方法です。一般的には1つのインストールコマンドで導入し、その後に認証方式とポートを自分で設定します。性能と制御性が高く、長期運用に適しています。インストール後は自動起動を有効にしてください。そうしないと、サーバーを再起動した際にプロキシも停止します。
認証方式とポート
認証は大きく3段階に分けられ、安全性は順に高くなります。ユーザー名とパスワードは最も簡単ですが、パスワードが漏れると実質的にプロキシへのアクセスを渡すことになります。パスワードに接続元IPの許可リストを組み合わせれば、日常利用には十分なことが多いです。鍵または証明書による認証が最も堅牢ですが、設定はやや複雑で、長期運用するアカウントなら手間をかける価値があります。
ポートについては、サービス自身の待受ポートを設定するだけでは不十分です。OSのファイアウォールと事業者のセキュリティグループの両方で、同じポートを個別に許可する必要があります。これらは独立した設定で、一方しか開けていないことが接続できない典型的な原因です。また、待受アドレスをローカルループバックだけにバインドしないようにします。サーバー内のテストでは通るのに外部から接続できない場合、ここが原因である可能性が高いです。
クライアントから接続して確認する
環境管理ツールで新しい環境を作成し、名前とメモを入力します。アカウントの用途と対象地域を名前に含めると、アカウント数が増えたときに管理しやすくなります。次にプロキシの種類に応じて、サーバーアドレス、ポート、ユーザー名、パスワードを設定し、接続テストを実行します。成功と表示されれば経路は通っています。具体的な項目名はツールの画面に従ってください。
接続テストに通るのは最初の一歩です。環境を開き、さらに3点を確認します。
1つ目は、出口IPがサーバーのパブリックIPになっているかです。現在のIPを表示するページを開き、サーバーのアドレスが表示されていれば正しく経由しています。
2つ目は、DNSもプロキシ経由になっているかです。DNSがローカルで解決されたままだと、外部に見える地理情報と出口IPが一致せず、アカウントに設定した地域との整合性が崩れます。
3つ目は、タイムゾーンと言語が出口地域に合っているかです。米国のIPなのに中国のタイムゾーンと中国語を使っている状態は、明確な不一致です。
3項目すべてを確認してから、その環境を利用可能と判断します。
接続できないときはこの順序で確認する
プロキシテストがすぐ失敗する場合は、まず疎通を確認します。セキュリティグループとOSファイアウォールの両方でポートが許可されているか確認し、次にプロキシサービスが動作しているかを確認します。特にサーバー再起動後は重要です。その後、ユーザー名とパスワード、サーバーアドレスが正しいかを確認します。パブリックIPとプライベートIPの取り違えはよくあるミスです。
テストは通るのにページが開かない場合、問題は環境側にあることが多いです。正しいプロキシが紐付いているか、DNS設定がローカル解決に戻っていないかを確認します。
速度が遅い場合は、距離と帯域のどちらが原因かをまず切り分けます。サーバーから直接対象サイトへアクセスしてみます。サーバー自体が遅ければノード地域または回線経路の問題で、サーバーは速いのにクライアントが遅ければ、帯域不足か同時オンラインのアカウントが多すぎる可能性があります。
アカウントが増えたときの拡張
1台のサーバーで複数アカウントを使えばコストは下がりますが、全アカウントが同じ出口IPを共有します。プラットフォームがIP帯で関連性を判断する場合、アカウント同士に関連が残る可能性があります。1アカウント1サーバーはコストが高くなる一方、環境を完全に分離できるため、価値の高いアカウントではより堅実な選択です。
PurpleMarkのような環境管理ツールで各アカウントに個別の出口を割り当てるほうが、手作業で対応表を管理するより安定します。軽量サーバーの一般的な料金であれば、1アカウント1出口のコストは多くの場合で許容範囲であり、関連付けが原因で後からアカウントを作り直す手間も減らせます。さらにテスト専用のサーバーを1台用意し、すべてのアカウントを1台に集中させないようにします。単一障害点が発生すると、全アカウントが同時に影響を受けるためです。
