Shadowsocks と Xray：VPN がブロックされるとき

私は仕事で VPN を扱うことが多い。理論としてではなく、現場の作業としてだ。拠点を接続し、顧客を社内ネットワークへ入れ、サーバーを到達可能に保ち、ファイアウォールを設定し、証明書を更新し、IPsec トンネルを安定させ、SSL VPN クライアントをデバッグし、ある拠点が突然つながらなくなった理由を調べる。

普通は地味で堅実なネットワーク作業だ。それでよい。

しかし、技術的には正しい VPN だけでは足りない場面がある。中国やロシアのようにインターネット規制が強い国の顧客では、従来型 VPN プロトコルがブロックされたり、劣化させられたり、意図的に検出されたりするケースがある。私はドバイで非常に国際的な顧客と仕事をしているので、これは抽象的な話ではない。運用上の問いは、政治的背景そのものではなく、接続経路がフィルタされる中で、どう正当なインフラアクセスを維持するかだ。

そこで Shadowsocks、ShadowsocksR、V2Ray、Xray-core、VLESS、Trojan、REALITY、XHTTP といった名前が出てくる。最初はプロジェクト、フォーク、略語が混ざった混乱に見える。正直に言えば、その一部は本当にそうだ。

Shadowsocks が生まれた理由

Shadowsocks は従来のエンタープライズ VPN の世界から生まれたものではない。より美しい site-to-site ソリューションを作るためでも、IPsec が複雑すぎたためでもない。出発点はもっと直接的だった。2012 年、clowwindy という名前の開発者が、強くフィルタされたネットワークからオープンなインターネットへ出るための軽量な方法を必要としていた。

この背景は設計をよく説明している。Shadowsocks は軽く、速く、実用的であるべきだった。重い VPN クライアントでも、大きなゲートウェイ製品でも、ID 管理やコンプライアンス報告を備えたリモートアクセススイートでもない。ローカルの SOCKS5 プロキシがトラフィックを暗号化し、ブロックの外にあるサーバーへ送る、という考え方だ。

求められていたのは「企業向けセキュリティ機能の追加」ではなく、「特定のプロトコルや宛先をフィルタするネットワークから使える出口」だった。そのため Shadowsocks は今でも興味深いが、同時に誤解もされやすい。軽量な transport component としては優れているが、それだけで完全な企業 VPN になるわけではない。

2015 年には、話は政治的になった。clowwindy は GitHub で、警察が来て作業を止めなければならないと書いた。その後、開発はフォークや別実装を通じて続いた。この種のツールは具体的な技術的痛みから生まれ、やがて利用者、開発者、フィルタリング基盤の間の大きな競争の一部になることが多い。

VPN がなぜ目立つのか

VPN と聞くと、多くの人はまず暗号化を考える。それは正しいが、一部にすぎない。

検閲システム、プロバイダ、大規模な国家ファイアウォールは、暗号化された通信の中身を読めなくても妨害できることがある。多くの場合、外側の形を識別できれば十分だ。IPsec、SSL VPN、WireGuard、OpenVPN には、ポート、パケットサイズ、ハンドシェイクのパターン、証明書の挙動、タイミング、UDP の使い方、再試行、エラー、既知のサーバー IP といった特徴がある。

手紙の本文ではなく封筒を考えると分かりやすい。本文は暗号化されているが、封筒にはサイズ、色、消印、同じ差出人といった特徴がある。封筒だけを仕分けする人は本文を読む必要がない。それでも「この種類は知っている。特別検査へ」と判断できる。

ネットワークトラフィックも似ている。Deep Packet Inspection や Traffic Classification はポートだけを見ない。パターンを分析する。TLS では Client Hello fingerprint、SNI、証明書チェーン、ALPN が目立つことがある。完全に暗号化されたプロトコルでは、初期パケットがあまりにランダムに見えること自体がシグナルになり得る。Great Firewall に関する研究は、初期パケットの長さ、エントロピー、印字可能な ASCII 文字も重要であることを示している。

不都合な点は、「全部ランダムに見える」ことが自動的に目立たないことを意味しないことだ。むしろそれが疑わしい場合もある。

研究が示していること

重要なのは、検閲システムが「VPN を検出できる」という事実だけではない。それは大まかには以前から知られていた。興味深いのは、多くの検出が技術的にはかなり地味なところから始まることだ。

良い入口は、GFW Report が 2020 年に ACM Internet Measurement Conference で発表した測定研究である。GFW Report は製品でもベンダーでもなく、Great Firewall に関する研究と測定のプロジェクトだ。

この研究の要点は、魔法の復号攻撃ではなかったということだ。Great Firewall は受動的観測と能動的 probing を組み合わせていた。最初に、最初のデータパケットの長さやエントロピーによって接続が疑わしくなる。次に、検閲側が疑わしいサーバーへ自分で接続し、古いパケットや変更したパケットを再生し、相手が Shadowsocks サーバーのように反応するかを見る。

管理者にとって、これは二つの防御層を示している。

• トラフィックは受動的観測で目立ちすぎてはいけない。
• サーバーは能動的テストに対してプロキシのように応答してはいけない。

2023 年には、別の GFW 研究が、完全に暗号化されたトラフィックも単純なヒューリスティックでブロックされ得ることを示した。最初の TCP payload が TLS にも HTTP にも印字可能テキストにも見えず、ランダムなデータブロックに見える場合、それ自体がシグナルになり得る。したがって「最大限ランダム」は常に最良の camouflage ではない。

2024 年の encapsulated TLS handshakes に関する研究は、さらに別の問題を示した。外側のトンネルが暗号化され、うまく偽装されていても、内側の TLS handshake がネストしたプロトコルスタック内のパターンとして見えることがある。ランダム padding の効果は限定的で、stream multiplexing はより有望に見えるが、最終的に一つの application stream だけが見えているなら自動的には解決しない。

Timing と cross-layer RTT も重要だ。プロキシは transport session と application session をずらす。この時間差は、クライアントがプロキシに近くても遠くても測定可能なことがある。別の header を設定するだけで消せるものではない。

結論は地味だが健全だ。決めるのはプロトコル名ではなく、setup 全体の挙動である。

Shadowsocks は古典的な VPN ではない

Shadowsocks はよく VPN と同じ箱に入れられる。日常会話では理解できるが、技術的には正確ではない。

Shadowsocks は SOCKS5 にゆるく基づいた暗号化プロキシだ。ローカルクライアントがアプリケーションにプロキシを提供し、トラフィックを暗号化してリモートの Shadowsocks サーバーへ送る。サーバーは要求を復号し、本来の宛先へ接続し、応答を暗号化経路で返す。

これは完全な VPN より軽い。Shadowsocks は OS 全体を自動的にトンネルへ入れない。選択したトラフィックを別経路へ送る道具である。クライアントや OS、追加コンポーネントによって VPN に近い体験を作ることはできるが、基本思想は site-to-site VPN ではなく proxy だ。

管理者にとって重要な整理は次の通り。

• Shadowsocks は適切な site-to-site IPsec を置き換えない。
• Shadowsocks はあらゆる検出を防ぐ魔法ではない。
• Shadowsocks は、制限ネットワークから単純で高速な encrypted proxy が必要なときに役立つ。

Shadowsocks は技術的に進化してきた。古い stream cipher の設定を基準にすべきではない。現代の deployment は AEAD の世界に属し、Shadowsocks 2022 は pre-shared symmetric key、BLAKE3-based derivation、replay protection などを追加している。ただし重要な制限がある。仕様上、Forward Secrecy は提供しない。鍵が漏れたら、きちんとした rotation は必須だ。

shadowsocks-rust は現代的な実装で、Docker でも動かせる。サーバー側では ssserver、クライアント側では sslocal などを使う。必要なのは適当な password ではなく、正しく生成された secrets、到達可能な port、現在の cipher、そして TCP、UDP、または両方を使うかの明確な判断だ。

Xray-core が別カテゴリである理由

Xray-core は単なる「新しい Shadowsocks」ではない。proxy と tunnel のための framework に近い。

Xray は VLESS、VMess、Trojan、Shadowsocks、WireGuard、Hysteria、SOCKS、HTTP などの inbound/outbound protocol を組み合わせられる。さらに RAW、WebSocket、gRPC、XHTTP、Hysteria などの transport と、TLS、REALITY、XTLS Vision を組み合わせる。VMess は古い構成には残っているが、新規 deployment では legacy 寄りで、現在の Xray では VLESS が中心になることが多い。

Shadowsocks はすぐ使えるドライバーのようなものだ。Xray は工具箱である。単純な構成も作れるが、ローカル SOCKS/TUN クライアントがトラフィックを受け取り、REALITY 付き VLESS でサーバーへ送り、そこから freedom outbound でインターネットへ出るような構成も作れる。

VLESS は camouflage そのものではない。UUID 認証を持つ軽量 proxy protocol だ。機密性と実際の偽装効果は、その下の transport/security layer、つまり TLS、REALITY、XTLS Vision などから来る。

REALITY が面白いのは、単に「もう一度 TLS」をするのではない点だ。外部から見ると、サーバーは実在する第三者の HTTPS サイトの TLS handshake を借りる。観測者には自作 proxy 証明書ではなく、実在サイトの実在証明書に見える。認可されたクライアントだけが、設定された key material によって、自分の Xray サーバーと話していることを認識する。

これは主に server-side TLS fingerprint と active probing を対象にしている。uTLS はクライアント側で browser Client Hello を模倣する助けになる。ただし Xray は透明マントではない。timing、packet sizes、ALPN、server behavior、nested TLS patterns は引き続きシグナルになり得る。XTLS Vision と XHTTP は有用な部品だが保証ではない。基本パターンが見えているなら、少しの padding では足りない。

Hysteria や QUIC のような UDP ベースの方式は高速になり得るが、制限ネットワークでは出力 TCP/443 よりも制限やブロックを受けやすい。だから Xray の運用には Shadowsocks よりも規律が必要だ。version を固定し、変更をテストし、release notes を読み、フォーラムのおすすめを盲目的にコピーしない。

Fork と名前の混乱

調べ始めると、古いブログ記事、GitHub fork、半分だけ保守されたクライアントにすぐ行き当たる。これはこれらのツールの歴史による。

Shadowsocks は protocol であり、複数の実装を持つ ecosystem でもある。現代的なサーバーを運用するなら、shadowsocks-rust は自然な選択肢だ。shadowsocks-libev のような古い実装も知られているが、プロジェクト状態によっては legacy または bugfix-oriented と見るべきだ。

ShadowsocksR は追加の obfuscation アイデアを持つ歴史的 fork だった。SSR は古いガイドに多く登場する。今なら慎重になる。古いインストールがすべて悪いからではなく、client、server、crypto、updates、community をきちんと確認する必要があるからだ。

Xray-core は V2Ray 周辺から生まれたが、独自に発展している。古い V2Ray チュートリアルをそのまま Xray に使うのは危険だ。概念は似ていても、設定、機能、推奨事項は変わっている。

V2Fly は V2Ray の community project として今も重要で、より保守的な toolkit だ。Xray-core は REALITY、XTLS Vision、XHTTP などの新機能により積極的である。sing-box も多くの protocol をまとめる現代的な platform として存在する。この記事では Xray に焦点を置くが、lab では sing-box も見る。

実務上の助言は次の通り。

• 新しい単純な setup: 現在の Shadowsocks 実装を検討する。
• より難しいネットワーク: Xray-core をクリーンで新しい設計で検討する。
• 古い SSR/V2Ray ガイド: まず project status と security を確認する。
• 顧客 production: 理解していない構成をコピーしない。

両側に必要なもの

最小構成には必ず二つの側がある。

リモート側には、制限ネットワークの外にある server が必要だ。小さな VPS、自社の datacenter server、または顧客拠点から到達できる地域の管理された infrastructure である。この server は hardening、patching、monitoring、documentation が必要だ。安い instance を立てて忘れるのは長期的なリスクになる。

クライアント側には適切な program が必要だ。Shadowsocks では local SOCKS client や system proxy を設定する app が多い。Xray では Xray-based client、TUN mode、router setup、profile を import する app があり得る。

さらに必要なのは次のものだ。

• 明確な目的
• きれいな authentication
• 最新の software versions
• 制御された DNS resolution
• 不要な顧客データを残さない logging
• reachability monitoring
• server、port、secrets の rotation plan
• 法的・契約上の確認

最後の点は飾りではない。国によっては、この種のツールの使用自体が法的に問題になることがある。企業では、自社システムを到達可能にするのか、顧客ネットワークを運用するのか、従業員に一般インターネットアクセスを提供するのかも区別しなければならない。

DNS はよく過小評価される。browser や OS が依然として local provider 経由で domain を解決しているなら、tunnel の効果は半分だけだ。content は proxy を通っても、DNS query が宛先を明かす。したがって DNS path、IPv6、tunnel 断時の動作を別途確認する必要がある。

Logging も繊細だ。troubleshooting では tunnel が生きているかを見たい。privacy と顧客保護では、保存を最小限にしたい。良い setup は destination domain の完全な接続リストではなく、technical state、latency、error rate、volume indicators を集める。Debug logs、TLS keylogs、unmasked access logs は production に残すべきではない。

Monitoring は container が動いているかだけでは足りない。実際の test path が tunnel を通るか、DNS が正しく routed されるか、特定 region が突然 block されていないか、影響を受ける国から見た状態がオフィスから見た状態と違うかを確認する必要がある。

運用上どう位置付けるか

私にとって Shadowsocks や Xray は firewall architecture、Zero Trust、MFA、clean segmentation の代替ではない。特殊ケースのための transport tool だ。

企業での現実的な流れは次のようになる。

1. まず SSL VPN、IPsec、WireGuard が安定して動くか確認する。
2. ブロックされるなら、DNS、port、protocol、server IP、TLS fingerprint、UDP throttling を測る。
3. 次に Shadowsocks や Xray-core などの alternative transport を試す。
4. Tunnel は必要な宛先だけに使い、顧客ネットワーク全体を開かない。
5. Server 側で到達可能な内部サービスを厳しく filter する。
6. 再ブロックを顧客から聞く前に分かる monitoring を作る。
7. fallback を持つ: second exit、別 provider、別 region、別 protocol。
8. secrets と client profiles を site または user ごとに分離する。
9. operation が可能で、不要な痕跡を残さない logs と metrics を作る。

顧客がシステムにアクセスできないとき、「とにかく戻った」だけで成功と感じたくなる。理解できる。しかしその後に片付けて document しなければ、一時的 workaround が誰も把握していない production path になる。

ブロックが追いついてくる理由

この種のツールでは、相手側も検出を継続的に調整していることを忘れてはいけない。

多くの人が同じ Docker Compose、同じ port、同じ TLS fingerprint、同じ domain strategy、同じ VPS provider を使えば、その pattern はやがて見える。抽象的な「Xray」や「Shadowsocks」がブロックされるのではなく、具体的な handshakes、packet sizes、IP ranges、typical clients、bad fallbacks、不自然な error responses がブロックされる。

Camouflage は tool の feature だけではない。運用でもある。同じ tool でも、domains、providers、client profiles、traffic patterns が違えば、実際の見え方は大きく変わる。

だから私は一部の project や community の主張に慎重だ。tool が「検出不能」と言うのは project claim である。paper が実際の network で特定の特徴が検出されたことを示すなら、それは別の重みを持つ。実務には、project の innovation speed と research の冷静さの両方が必要だ。

私の見方

Shadowsocks は、軽く、速く、比較的単純な encrypted proxy が必要なときに向いている。初期テスト、一時アクセス、極端に攻撃的な detection がない環境に向いている。

Xray-core は、ネットワークが難しい場合、複数 transport が必要な場合、または VLESS、REALITY、WebSocket、gRPC、XHTTP を意識して使いたい場合に向いている。ただしより多くの理解が必要で、柔軟な分、誤設定もしやすい。

顧客環境では、どちらも「VPN replacement」として売らない。正当なアクセスのための alternative transport path と説明する。派手ではないが、その方が正直だ。

結局、最重要なのは Shadowsocks 対 Xray ではない。自分が何の問題を解いているか理解しているかだ。普通の remote access なら普通の VPN を使う。国家や provider 側の protocol detection が問題なら、recognizability、fingerprints、operational strategy を話す必要がある。それを説明できないなら、顧客 production で運用すべきではない。

まとめ

Shadowsocks と Xray-core は、ネットワーク接続が単に「動く」か「動かない」かだけではない世界のツールだ。接続は分類され、帯域制限され、能動的にテストされ、ブロックされることがある。国際的な顧客を支援していれば、いずれこの現実に出会う。

このテーマが面白いのは、ネットワーク技術を非常に具体的にするからだ。暗号化だけでなく、patterns、fingerprints、routing、DNS、operations、law、responsibility、そして「動く tunnel が自動的に良い設計ではない」という事実が関係する。

次のステップは明確だ。Shadowsocks と Xray-core を小さな lab で再現したい。検閲を盲目的に回避するためではなく、従来型 VPN がなぜ目立つことがあるのか、どの alternative が技術的に真面目に運用できるのかを理解するためだ。

また次回、
Joe

FAQ