目次
自分でプロキシサーバー（ノード）を構築しようとすると、黒い画面に並ぶ無数のコマンドと聞き慣れない専門用語の山に圧倒されて挫折しがちです。初心者にはハードルが高すぎます。かといって市販の有料プロキシ業者（いわゆる「空港」）を使うと、頻繁にタイムアウトして接続が不安定だったり、ClaudeやChatGPTなどの厳格なサービスでアカウントごとBANされたりして手痛い思いをすることになります。
VLESS、Reality、Hysteria2、WARP——解説記事を開けば当たり前のように飛び交うこれらの単語ですが、それぞれが何を担っているのかを分かりやすく解説したものはほとんどありません。私の自作サーバーでもまさにこれらを組み合わせて運用しています。本記事では難しいコマンドのコピペは一切排し、各プロトコルの動作原理を根本から解き明かした上で、最終的にこれらをすべてAIに丸投げして自動構築させた実践フローを紹介します。
まずは「VPN」と「プロキシ」の違いを整理する
VPNはネットワーク層で動作します。インストールするとPCに仮想ネットワークカード（TUN）が作成され、デバイス全体のすべての通信トラフィックが1つの暗号化トンネルにまとめられます。一方、プロキシはより上位のアプリケーション層で動作し、個々の接続を中継します。世間で「VPN」と呼ばれているものの多くは、実際にはプロキシです。
プロトコルを評価する指標は基本的に3点あります。
- 通信内容が暗号化されているか
- 接続してきた相手が正規の自分（クライアント）だと認証できるか
- 通信トラフィックが「ごく普通の一般的なWeb閲覧」に見えるか（偽装・カモフラージュ）
古くからあるプロトコルは主に1と2を満たしていましたが、技術の進化に伴い、現代のプロトコルは3の「どうやって検閲や遮断の目を欺くか」に心血を注いできました。この流れさえ理解しておけば、以降の話がすんなり頭に入ってきます。
OpenVPN と WireGuard
これらは正真正銘の「純粋なVPNプロトコル」であり、企業のテレワークなどで日常的に使われています。OpenVPNはTLSハンドシェイクで鍵を交換した後にデータを暗号化します。WireGuardはより近代的なプロトコルで、UDP上で動作し、Noiseプロトコルフレームワークによるハンドシェイク、Curve25519による鍵交換、ChaCha20-Poly1305による暗号化を採用しています。コードベースが極めて小さく、高速に動作します。
しかし、これらは純粋なセキュリティと通信速度のために作られたものであり、「通信を隠す（カモフラージュする）」設計にはなっていません。WireGuardの最初のハンドシェイクパケットは常に148バイトで先頭に固有のタイプ識別子があり、OpenVPNのパケットも固定のオペコードで始まります。通信の特徴（シグネチャ）が固定されているため、ファイアウォールなどの監視装置からは一目瞭然で遮断されてしまいます。
Shadowsocks
かつて一世を風靡したプロキシプロトコルです。クライアントとサーバーで共通のパスワードを取り決め、クライアントは接続先アドレスとデータを共通鍵暗号で丸ごと暗号化して直接送信します。ハンドシェイクは存在しません。サーバーはそれを復号して接続先を取り出し、代理で通信して結果を暗号化して送り返します。
「すべての通信データを完全にランダムなゴミデータ（Blob）に見せかける」という発想でしたが、これこそが最大の弱点となりました。通常のインターネット通信は、TLSハンドシェイクのヘッダーやHTTPのリクエストメソッドなど、先頭に明確な書式を持ちます。世界中のトラフィックの中で「最初の一文字目から完全にランダムな意味不明のデータ」が流れていれば、それ自体が強烈なシグネチャ（特徴）となってしまうのです。実際、2021年末以降のファイアウォールは、接続の第1パケットのエントロピー（ランダム度）を検査し、怪しいものを一括遮断する手法を実戦投入しています。
さらに、過去のパケットを再送してサーバーの反応を伺う「アクティブプロービング（能動的探査）」にも弱く、一般的なWebサーバーとは異なる挙動を示すことで次々と検知されました。
VMess
V2Rayのネイティブプロトコルです。ユーザーごとにUUID（固有ID）を持ち、クライアントはUUIDと現在時刻を組み合わせてヘッダーに認証値を埋め込みます。サーバーも同じ計算を行い、一致した場合のみ通信を許可します。時刻が大きく狂っていると認証が通らないという特徴があります。
VMess単体でも内部暗号化を持っていますが、Shadowsocksと同様に「トラフィック全体がランダムに見える」ため検知されやすい問題がありました。そのため実務上はWebSocket + TLSでトンネリングして偽装することが一般的になり、結果として「同じデータを二重に暗号化する」という非効率なオーバーヘッドを抱えることになりました。
Trojan
Trojanはアプローチをガラリと変えました。「本物のTLS（HTTPS）」を使う方法です。サーバーに正規のドメインとSSL/TLS証明書を割り当て、クライアントは本物のHTTPS通信とまったく同一の標準TLSハンドシェイクを行います。
暗号化された正規のTLSパイプラインの中で、クライアントはパスワードのSHA224ハッシュと接続先アドレスを送信します。サーバーはハッシュが正しければプロキシ中継を開始し、もし不正なアクセスや外部からの探査だった場合は、裏で動かしている本物のWebサイトの画面を返します。これにより「3. トラフィックが正常なWebサイト閲覧に見える」という要件が初めて完全にクリアされました。
ただし、独自のドメイン購入と証明書の定期更新が必要であり、ドメイン自体がブラックリストに載ると使えなくなるという運用上の手間が残りました。
VLESS + Reality：現在の最適解
現在、最も広く支持されている組み合わせがこれです。
まずVLESS。これは「軽量版VMess」とも言えるプロトコルで、自身の余計な暗号化をすべて削ぎ落とし、認証用のUUIDだけを先頭に付与します。データ暗号化は外側のTLS層に完全に任せるため、二重暗号化のオーバーヘッドが一切なく、CPU負荷が極めて低く高速です。
そして真のブレイクスルーがRealityです。これまでのTLS偽装には「自前のドメインと証明書」が必要でしたが、Realityは他人の実在する大手正規サイト（YahooやApple、Microsoftなど）のTLS証明書をそのまま借用して偽装します。
クライアントが接続する際、SNI（接続先サーバー名）に偽装対象の正規ドメインを指定します。外部の監視装置から見れば、大手公式サイトへアクセスしているようにしか見えません。サーバー側では、クライアントが暗号化ハンドシェイクの中にこっそり埋め込んだ一時公開鍵と事前共有鍵を検証し、正規の認証が通ればプロキシとして接続を受け入れます。もし検閲装置などの第三者が探査（プロービング）をかけてきた場合、Realityサーバーは本物のターゲットサイトへ通信をそのまま横流しし、本物の証明書とWebレスポンスを返送します。
探査者からすれば「本物のWebサイトそのもの」に見えるため、偽装ノードであることを見破る手段が原理的に存在しません。ドメインを買う必要も、証明書を更新する必要もなくなりました。
Hysteria2：パケットロスの激しい回線での救世主
TCPベースの通信は、パケットロス（パケット抜け）が発生すると「回線が混雑している」と判断して送信速度を自動で落とす仕様（輻輳制御）になっています。しかし、国際回線のピークタイムに発生するパケットロスは回線の混雑とは無関係なノイズであることも多く、TCPは速度を落とし続けて最終的に這うような速度に落ち込んでしまいます。
Hysteria2は全く異なるアプローチをとります。UDPベースの「QUIC」プロトコルを採用しています。QUICには最初からTLS 1.3が組み込まれており、現在のHTTP/3の標準基盤です。
Hysteria2は、標準の輻輳制御の代わりに独自の「Brutal」アルゴリズムを採用しています。あらかじめ指定した帯域幅に合わせて猛スピードでパケットを送り続け、途中でロスしたパケットだけをアグレッシブに再送します。パケットが抜けても決して速度を落としません。また認証もHTTP/3リクエストの中に巧妙に隠蔽されており、認証が成功すると特殊なステータスコード「233」を返してプロキシモードに切り替わります。不正なアクセスにはごく普通のHTTP/3サイトとして応答します。
弱点としては、一部のネットワーク環境でUDPやQUIC自体が意図的に帯域制限されている場合、かえってTCPより遅くなることがあります。また、パケットロス時にも速度を落とさない挙動そのものが特徴として観測されやすいという側面もあります。そのため、私はRealityをメイン回線とし、ゴールデンタイムなどで回線品質が劣化したときの「非常用ブースト回線」としてHysteria2を併用しています。
WARP：AIサービスの地域制限とIPブロックを回避する
WARPはCloudflareが提供している「1.1.1.1」サービスの基盤技術です。通常はスマホアプリとして使われますが、これをVPSサーバー側にインストールして、サーバーからCloudflareへの出口トンネルを敷くという使い方をします。
Xrayの内部構造は「Inbound（入口）」「Outbound（出口）」「Routing（ルーティングルール）」に分かれています。通常、トラフィックはサーバー自身のVPSのIPから外部へ抜けていきます。しかし、データセンターのIPアドレス帯は公開されているため、ChatGPTやClaudeなどのAIサービスはデータセンターIPからの接続を機械的に弾き、「お住まいの地域ではご利用いただけません」とエラーを出します。
そこで、Xrayの出口ルールにWARPを追加し、AI宛ての通信だけをWARPトンネル経由（Cloudflareの一般家庭向けエッジIP）から出ていくようにルーティングします。これにより、IPブロックを綺麗にすり抜けることができます。余分なホップを挟むためわずかにレイテンシが増加しますが、AIサービスの判定を突破するには極めて効果的な手段です。
サブスクリプションURLによる一括同期
ノードの接続情報はvless://...やhysteria2://...で始まる1行の文字列で表されます。サブスクリプションとは、これら複数のノード情報をまとめたテキストをBase64でエンコードし、HTTPで配信する仕組みです。
クライアントソフト（Clash、Sing-box、Shadowrocket、v2rayNなど）にこのURLを登録しておけば、サーバー側の設定を変えてもURLを更新するだけで全デバイスに最新のノード一覧が即座に反映されます。このURL自体が全ノードへのアクセスキーとなるため、推測されにくいランダムなトークンをパスに含めて厳重に管理する必要があります。
私の現在の構成と、AIによる完全自動化
現在、私のサーバーはDigitalOcean（月額4ドル〜の最も安価なプランで十分動きます）上で稼働しています。Xrayをベースに、メイン回線はVLESS + Reality（直接ルーティング）、AI専用の出口としてWARP連携ルート、さらに予備回線としてHysteria2を同居させ、自作の軽量サブスクリプション配信サーバーから配信しています。
最初にこの環境を構築したときは、チュートリアル記事とにらめっこしながら、何十行ものLinuxコマンドを打ち込み、キーを生成し、JSON設定ファイルを編集し、ポートを開放し……設定ミスがあれば何時間もログと格闘していました。
しかし、ふと気づいたのです。「せっかくAIを使いこなしているのに、人間がこんな定型コマンドを手で打つ必要がどこにあるのか？」と。
そこで、サーバー構築、死活監視、トラブルシューティング、サブスクリプション移行の全工程をClaude向けの「Skill」として定義しました。今では新しいVPSを借りたら、IPアドレスをClaudeに渡すだけで、ClaudeがSSH経由でログインして全スタックを自動インストールし、最後に完成したサブスクリプションURLを手渡してくれます。万が一通信が途切れた際も、ヘルスチェックコマンドをAIに走らせれば「どのルートがなぜ落ちているか」を瞬時に特定して修復してくれます。
時代は変わりました。インフラ構築もAIに任せ、私たちはよりクリエイティブな創作に時間を使うべきです。
