VeilShift™でわかるDPI回避の実装差分

DEV Communityに、Veilora VPNの「VeilShift™」というDPI回避プロトコル解説が出ていた。
原題は How VeilShift™ Works — The Protocol That Bypasses DPI Blocking。

内容はかなり製品紹介寄りだが、構成要素はおもしろい。
VLESS + XHTTP + REALITY、uTLS、xPaddingBytesを組み合わせ、DPIが見ている複数の層を同時に潰す、という説明になっている。

既存記事では対中国通信 VPN規格によるつながりやすさの比較で VLESS + REALITY を最有力候補として扱い、別記事で VLESS + REALITY サーバー構築とクライアント接続の概要も書いた。
今回の話はそこから一段進んで、「TLSっぽく見せる」だけでは足りない場面で、何を追加で見るべきかという差分になる。

DPIは中身だけを見ているわけではない

DPI（Deep Packet Inspection）は、通信の宛先IPやポート番号だけでなく、パケットの中身や形を見て分類する仕組み。
ただし、暗号化された通信を全部復号して読んでいる、という意味ではない。

現実には、以下のような観測点を組み合わせる。

観測点	見られるもの	VPNが見つかる理由
プロトコル署名	最初の数バイト、ハンドシェイク、固定パターン	WireGuardやOpenVPNは通信開始時の形が比較的わかりやすい
TLSフィンガープリント	ClientHelloの拡張順序、暗号スイート、ALPN	VPNアプリやGo製クライアントのTLSがブラウザと違って見える
通信の時間的パターン	パケット間隔、上り下りの流れ	Web閲覧よりもトンネル通信っぽい流量になる
パケットサイズ分布	パケット長の偏り、一定サイズの繰り返し	暗号化されていても統計的に分類される

「443番ポートを使っているからHTTPSに見える」は、今だとかなり弱い。
HTTPSに見えるかではなく、Chromeが普通のサイトを見ている時のTLSや流量にどれだけ近いかが問題になる。

VeilShiftの構成

原典では、VeilShift™を次の組み合わせとして説明している。

VLESS + XHTTP + REALITY + uTLS + xPaddingBytes

それぞれの役割は分かれている。

flowchart TD
  A[DPIの観測] --> B[プロトコル署名]
  A --> C[TLSフィンガープリント]
  A --> D[パケットサイズ分布]
  A --> E[通信パターン]

  B --> F[VLESS + XHTTP + REALITY]
  C --> G[uTLS]
  D --> H[xPaddingBytes]
  E --> I[HTTPS上の長めの通信として扱う]

  F --> J[VPN固有の入口を薄める]
  G --> K[ブラウザ風のClientHelloに寄せる]
  H --> L[サイズ統計を崩す]
  I --> M[通常のWeb通信との差を減らす]

この図だけ見ると万能に見えるが、実務では「どの層に効くのか」を分けて見るほうがいい。
たとえば REALITY はTLS証明書やSNIまわりの見え方に効くが、パケットサイズ分布を直接ならす機能ではない。
uTLSはTLS ClientHelloの見え方に効くが、サーバーIPの評判や接続先ネットワークの品質までは解決しない。

VLESS + XHTTP + REALITYが隠すもの

VLESS は、Xray系で使われる軽量なトランスポートプロトコル。
それ自体で全部を暗号化するというより、外側のTLSやREALITYと組み合わせて使う前提の部品だ。

REALITYの狙いは、自己署名証明書や不自然なVPN用証明書を見せず、実在するHTTPSサイトに見えるTLS接続へ寄せること。
既存の VLESS + REALITY 記事では「実在サイトの証明書を借りる」と雑に書いたが、今回の文脈ではもう少し粒度を上げたほうがいい。

DPI側から見ると、雑なVPNサーバーはこう見える。

443番ポート
TLSっぽい
でも証明書やClientHelloや応答の癖が普通のWebサイトと違う

VLESS + REALITY は、この「TLSっぽいが普通のWebではない」という差を減らす。
XHTTPは、XrayのHTTP系トランスポートとして、通信をHTTPの形へ載せる層だ。
単にTCPの上に独自バイト列を流すより、Web通信として扱わせやすい。

ただし、この時点ではまだTLSフィンガープリントの問題が残る。
Goの標準TLSやVPNアプリ独自のTLS実装は、ChromeやSafariのClientHelloと違う形になりやすい。

uTLSでClientHelloをブラウザに寄せる

TLSフィンガープリントは、TLS接続開始時のClientHelloから作られる識別情報だ。
対応する暗号スイート、拡張の種類と順序、ALPN、GREASEの出方などで、クライアント実装の癖が出る。

uTLS はGoの crypto/tls をベースに、ClientHelloを細かく制御するライブラリ。
READMEでも、GoのClientHelloは特にモバイル環境で目立ちやすく、検閲回避ツールがClientHelloでブロックされる懸念に触れている。

VeilShift™の説明では、uTLSでChromeのフィンガープリントに合わせるとしている。
ここは効果が大きい一方で、かなり繊細な部分でもある。

たとえば2026年には、uTLSのChrome模倣でGREASE ECHまわりの不一致がCVEとして扱われた。
GitLab Advisory DatabaseのCVE-2026-27017 によると、Chromeの挙動とuTLS側の選択が一致しない組み合わせがあり、観測者から見ると「Chromeでは起きない形」になり得た。

つまり、「Chromeと同一」と言い切るには、利用しているuTLSのバージョン、対象Chromeバージョン、ECHやALPNの扱いまで見る必要がある。
製品ページの成功率より、まず実装が追随できているかを見るほうが実務的だ。

xPaddingBytesはサイズ分布への対策

暗号化しても、パケットサイズは見える。
通信内容は読めなくても、何バイト程度のパケットがどの頻度で流れるかは観測できる。

ここで効くのが xPaddingBytes だ。
XHTTP系のトランスポートでは、ランダムなパディングを入れてパケットサイズの偏りを崩す。
Project XのTransportドキュメントでも、XHTTPまわりにパディング設定が出てくる。

これは機械学習ベースの分類に対する対策として意味がある。
ただし、パディングは無料ではない。
帯域を余計に使うし、モバイル回線では電池やレイテンシにも響く。

見るべきなのは「パディングがあるか」だけではない。
最小値と最大値、ランダム性、上り下りの比率、長時間接続時のサイズ分布が、実際のWeb通信に近いかを見る必要がある。

DPI回避のアプローチの変化

従来の回避策は、だいたい「VPNをHTTPSに載せる」発想だった。
V2Ray + WebSocket + TLS、Trojan、OpenConnect、SoftEtherのSSL-VPNなどがこの系統に入る。

VeilShift™の説明で新しいのは、HTTPS化だけでなく、DPIの観測点を分解して対応しているところだ。

世代	主な狙い	弱点
ShadowSocks	軽量な暗号化プロキシ	トラフィックの癖が知られると検出されやすい
V2Ray WebSocket + TLS	HTTPS風に見せる	TLSフィンガープリントや流量パターンが残る
VLESS + REALITY	証明書やSNIの不自然さを減らす	サイズ分布やClientHelloの追随が別問題になる
VeilShift型の構成	REALITY、uTLS、パディングを重ねる	実装更新と検証の負荷が上がる

今回のVeiloraの解説は、単に自社プロトコルの優位性を語るだけでなく、VPN回避技術の比較軸が変わったことを示している。
VPN比較記事で評価する際も、単なるプロトコル名ではなく、TLS指紋、パディング、HTTPトランスポート、運用ネットワークまで含める必要がある。

適用環境とオーバースペックな用途

この構成が活きる可能性が高いのは、標準的な商用VPNが国やISP単位で止まりやすい環境だ。
原典ではトルコ、UAE、インドネシアを例に出している。
中国向けで語られがちなGFW対策と同じ問題設定だが、国ごとに検出ルールや遮断の荒さは違う。

逆に、次のような用途では過剰になる。

日本国内から自宅やVPSへ安全に入るだけなら、WireGuardやTailscaleのほうが扱いやすい
企業の閉域接続なら、監査しやすいIKEv2、WireGuard、OpenConnectを優先したほうがいい
UDPが普通に通る環境で速度重視なら、Hysteria2 のほうがシンプルな場合がある

DPI回避は、強化するほど設定と検証が難しくなる。
「つながる」だけでなく、切断時の漏れ、DNS、IPv6、アプリごとのプロキシ漏れも考慮しなければならない。

商用VPNの実態評価

VeilShift™のような構成を評価するなら、宣伝上の成功率より以下の実装状況を見るほうが確実だ。

観点	確認すること
TLSフィンガープリント	uTLSのバージョン、Chrome追随、ECHやALPNの扱い
トランスポート	XHTTPなのかWebSocketなのか、HTTP/2やHTTP/3をどう使うか
パディング	xPaddingBytesの範囲、帯域増加、モバイル回線での遅延
サーバーIP	VPSのAS番号、IPレンジの評判、同一IPの使い回し
DNS	接続前の名前解決が漏れていないか
Kill Switch	VPN切断時に全通信が止まるか
ログ	接続ログ、転送量ログ、アカウント識別情報の扱い

特に商用サービスの場合、同じVLESS + REALITYでも、uTLSが古い、パディングが弱い、サーバーIPがまとめてブロックされている、というだけで結果は変わる。

自前でXrayを立てる場合、3X-UIやMarzbanを使えばVLESS + REALITYやXHTTPの設定は近いものが作れる。
しかし商用VPNは、プロトコル更新への追随、多数のIPの確保、Kill Switchを統合したアプリの提供などをサービス側で巻き取る点が異なる。
Veiloraが全サーバーでVeilShift™を標準化しているなら、ユーザーが「難読化モード」を探さなくていい点はわかりやすい。
一方で、外から検証できる情報は限られており、99%成功率のような数字は、測定期間、国、ISP、端末、接続回数、失敗判定の定義がないと評価しづらい。
今日効いたTLS模倣が、次のChrome更新やuTLS更新でズレることもあれば、サーバーIPの評判やAS単位の遮断でプロトコル以前に落ちることもある。