Vmess や Shadowsocks などのクライアントは、デバイスのローカル マシン上で HTTP ソケット リスナー ポートを開きます。これは、本質的にはトランスポート層リレー ブリッジ ルーターの一種です。
Posted: Sun Jan 18, 2026 5:11 am
Vmess や Shadowsocks などのクライアントは、デバイスのローカル マシン上で HTTP ソケット リスナー ポートを開きます。これは、本質的にはトランスポート層リレー ブリッジ ルーターの一種です。
https://github.com/2dust/v2rayN/releases
アプリケーション/トランスポート層の vmess プロトコルが、極端な国/地域 (中国の GFW など) の高 DPI ファイアウォールをバイパスできるようになったと仮定すると、https://github.com/2dust/v2rayN/releases などのすべてのローカル クライアントは、ローカル リスニング ポートでポート 127.0.0.1:1080 を開きます。
ポートが LAN 内にある場合、LAN 内のデバイスは、このポートを介して他の VPN プロトコル (TCP/UDP) を透過的に送信できます。これは、ネットワーク上で透過プロキシと呼ばれます。
しかし、PC上での実装は非常に簡単で、TUN/TAPアダプタと呼ばれる技術も実装されていますが、PC上で仮想NATルーターを構築するのは、SoftEtherVPNクライアントをダウンロードするだけです。
このソフトウェアはTAP/TUNアダプタを実装しており、オペレーティングシステム内に仮想ハブデバイス（ローカルブリッジ、またはローカルブリッジ経由でブリッジされたSoftEtherVPN仮想ハブ）を作成するだけで済みます。https://github.com/clash-verge-rev/clas ... v/releases
ただし、ネットワークAPIの権限制限により、iOSやAndroidなどのモバイルデバイスでは、この機能をトランスポート層でしか実装できません。
このように、vmessやshadowsocksといった新しいタイプのプロキシ（VPNではない）を経由するすべてのデータ接続は、ローカルの高強度DPIファイアウォールを容易にバイパスできます。基盤となるトランスポートプロトコルはSoftEtherのSE-VPNプロトコルではありませんが、少なくとも「TAP/TUNアダプタ」のソフトウェア実装モードは、ソフトウェアカーネル内でリンクを集約するだけです。
Vmess Shadowsocks が DPI ファイアウォールを回避できる鍵は、そのプロトコル特性にあると考えられます。もし SoftEther が特定の国/地域の DPI ファイアウォールによるパケット傍受を回避するために、特別に細工されたハンドシェイクパケットを事前に設定していたとしたら、
SoftEtherVPN の SE-VPN プロトコルは、これらの国/地域でこれほど広く採用できたでしょうか？
現在、これらの国/地域のユーザーは SoftEtherVPN の SE-VPN プロトコルに強い抵抗を示しているようです。彼らの直感は、DPI の厳格な検閲に耐性のないプロトコルは役に立たないと考えており、継続的なプロモーションは報われない仕事のように思われます。
個人的には、SoftEther-VPN の SE-VPN プロトコルの方が好みです。少なくとも機能モジュールは RFC 標準に準拠しているからです。しかし、新しい通信プロトコルでは、偽の IP/DNS の特殊処理や RFC に準拠しない通信動作が導入されています。これらのプロトコルは DPI ファイアウォールを通過できないわけではありませんが、それらをバイパスするように特別に開発されています。
私は、SoftEther を vmess や shadowsocks などのツールと「どちらのプロトコルが DPI ファイアウォールの通過により効果的か」という観点から比較することはありません。RFC 準拠の観点から言えば、SoftEtherVPN のプロトコルスタック全体が自発的かつ非暴力的に、広く受け入れられている RFC 標準に準拠しているだけです。
現在、これらの 2 つの非常に人気のあるアプリは iTunes.com で簡単に見つけることができます。
https://apps.apple.com/jp/app/sstp-connect/id1543667909
https://apps.apple.com/jp/app/shadowrocket/id932747118
https://www.vpnusers.com はインターネット上で完全にオープンであり、SoftEtherVPN や一部の一般的なサードパーティ製プロトコルについて、誰もが透明性を持って議論できる場となっています。私は個人的にこれらのプロトコルを推奨も否定もしていません。特定の技術実装について議論するためだけに投稿しています。
さらに、開発者や技術専門家が参加して議論できる、海外の Telegram 公開グループを作成しました。
https://t.me/VPNGate_Oscar
https://github.com/2dust/v2rayN/releases
アプリケーション/トランスポート層の vmess プロトコルが、極端な国/地域 (中国の GFW など) の高 DPI ファイアウォールをバイパスできるようになったと仮定すると、https://github.com/2dust/v2rayN/releases などのすべてのローカル クライアントは、ローカル リスニング ポートでポート 127.0.0.1:1080 を開きます。
ポートが LAN 内にある場合、LAN 内のデバイスは、このポートを介して他の VPN プロトコル (TCP/UDP) を透過的に送信できます。これは、ネットワーク上で透過プロキシと呼ばれます。
しかし、PC上での実装は非常に簡単で、TUN/TAPアダプタと呼ばれる技術も実装されていますが、PC上で仮想NATルーターを構築するのは、SoftEtherVPNクライアントをダウンロードするだけです。
このソフトウェアはTAP/TUNアダプタを実装しており、オペレーティングシステム内に仮想ハブデバイス（ローカルブリッジ、またはローカルブリッジ経由でブリッジされたSoftEtherVPN仮想ハブ）を作成するだけで済みます。https://github.com/clash-verge-rev/clas ... v/releases
ただし、ネットワークAPIの権限制限により、iOSやAndroidなどのモバイルデバイスでは、この機能をトランスポート層でしか実装できません。
このように、vmessやshadowsocksといった新しいタイプのプロキシ（VPNではない）を経由するすべてのデータ接続は、ローカルの高強度DPIファイアウォールを容易にバイパスできます。基盤となるトランスポートプロトコルはSoftEtherのSE-VPNプロトコルではありませんが、少なくとも「TAP/TUNアダプタ」のソフトウェア実装モードは、ソフトウェアカーネル内でリンクを集約するだけです。
Vmess Shadowsocks が DPI ファイアウォールを回避できる鍵は、そのプロトコル特性にあると考えられます。もし SoftEther が特定の国/地域の DPI ファイアウォールによるパケット傍受を回避するために、特別に細工されたハンドシェイクパケットを事前に設定していたとしたら、
SoftEtherVPN の SE-VPN プロトコルは、これらの国/地域でこれほど広く採用できたでしょうか？
現在、これらの国/地域のユーザーは SoftEtherVPN の SE-VPN プロトコルに強い抵抗を示しているようです。彼らの直感は、DPI の厳格な検閲に耐性のないプロトコルは役に立たないと考えており、継続的なプロモーションは報われない仕事のように思われます。
個人的には、SoftEther-VPN の SE-VPN プロトコルの方が好みです。少なくとも機能モジュールは RFC 標準に準拠しているからです。しかし、新しい通信プロトコルでは、偽の IP/DNS の特殊処理や RFC に準拠しない通信動作が導入されています。これらのプロトコルは DPI ファイアウォールを通過できないわけではありませんが、それらをバイパスするように特別に開発されています。
私は、SoftEther を vmess や shadowsocks などのツールと「どちらのプロトコルが DPI ファイアウォールの通過により効果的か」という観点から比較することはありません。RFC 準拠の観点から言えば、SoftEtherVPN のプロトコルスタック全体が自発的かつ非暴力的に、広く受け入れられている RFC 標準に準拠しているだけです。
現在、これらの 2 つの非常に人気のあるアプリは iTunes.com で簡単に見つけることができます。
https://apps.apple.com/jp/app/sstp-connect/id1543667909
https://apps.apple.com/jp/app/shadowrocket/id932747118
https://www.vpnusers.com はインターネット上で完全にオープンであり、SoftEtherVPN や一部の一般的なサードパーティ製プロトコルについて、誰もが透明性を持って議論できる場となっています。私は個人的にこれらのプロトコルを推奨も否定もしていません。特定の技術実装について議論するためだけに投稿しています。
さらに、開発者や技術専門家が参加して議論できる、海外の Telegram 公開グループを作成しました。
https://t.me/VPNGate_Oscar