より高速なSASEクライアント：プロキシモードの再構築
CloudflareはSASEプラットフォーム「Cloudflare One」のプロキシモードを再構築し、従来のWireGuard（L3）からQUICベースの直接L4プロキシングへ移行することで、パフォーマンスとセキュリティの両立を実現した。
キーポイント
従来の技術的課題
既存のクライアントはWireGuard（L3）を使用していたため、アプリケーション層（L4）のTCPトラフィックを処理するためにユーザー空間のTCPスタック「smoltcp」を使用しており、これがパフォーマンスのボトルネックとなっていた。
QUICを活用したアーキテクチャ刷新
Cloudflare One Clientのプロキシモードを再構築し、WireGuardの使用を非推奨とし、QUICストリームを用いた直接L4プロキシングを採用した。
HTTP/3とCONNECTメソッドの活用
RFC 9114で定義されるHTTP/3のCONNECTメソッドを利用し、トラフィックをL3パケットに分解することなくQUICストリームに直接カプセル化し、レイテンシを削減した。
パフォーマンスの大幅な向上
複数の並列接続を必要とするメディア集約型サイトにおいて、高レイテンシや読み込みの遅延が解消され、高速ファイバー接続環境でもプロキシモードの速度が劇的に改善された。
3つの主要ユースケースの最適化
既存VPNとの併用（ゼロトラスト追加）、高帯域幅アプリの分離、およびSOCKS5経由の開発者向けCLIツールのパフォーマンスが改善されました。
導入方法と要件
Windows/macOS/Linux向けクライアントバージョン2025.8.779.0以降で利用可能であり、ダッシュボードでService modeをLocal proxy mode、Device tunnel protocolをMASQUEに設定する必要があります。
影響分析・編集コメントを表示
影響分析
この変更は、エンタープライズセキュリティにおける「セキュリティとパフォーマンスのトレードオフ」という長年の課題を解決する重要な一歩である。特に、クラウドネイティブなネットワークアーキテクチャにおいてQUICの採用が標準化されるにつれ、従来のTCP/IPスタックに依存しないプロキシリング手法が、次世代のSASEソリューションにおける競争優位性の鍵となる。
編集コメント
セキュリティプロキシのボトルネック解消は実務上の重要課題であり、QUICの活用事例として技術的に成熟度が高い。
タイトル: より高速なSASEクライアント: Proxy Modeの再構築
ゼロトラスト環境のセキュリティを維持するためにプロキシを使用する必要がある場合、それはしばしば代償を伴います: ユーザーにとってのパフォーマンスの低下です。クライアントプロキシを導入するとすぐに、セキュリティチームは通常、ブラウザの速度低下、ファイル転送の遅延、そしてちょうど悪いタイミングで途切れるビデオ通話に不満を持つユーザーからの大量のサポートチケットに直面します。しばらくすると、その原因をプロキシのせいにするようになり始めます ― パフォーマンスに影響を与える他の問題を見逃してしまう可能性があります。
私たちは、これが必然ではないことを知っていました。プロキシモードへのアプローチを完全に再構築すれば、セキュリティを犠牲にすることなく、ユーザーがより高速に利用できることを確信していました。だから私たちはそれを実行しました。
当社のSASEプラットフォーム「Cloudflare One」のデバイスクライアント開発の初期段階では、普遍的な互換性を優先しました。管理者がプロキシモードを有効にすると、クライアントはローカルのSOCKS5またはHTTPプロキシとして機能しました。しかし、基盤となるトンネルアーキテクチャがレイヤー3（L3）プロトコルであるWireGuard上に構築されていたため、技術的な課題に直面しました: アプリケーション層（L4）のTCPトラフィックを、どのようにL3トンネルに流し込むかという問題です。L4からL3への移行は特に困難でした。なぜなら、当社のデスクトップクライアントは複数のプラットフォーム（Windows、macOS、Linux）で動作するため、カーネルを利用してこれを実現することができなかったからです。
この課題を克服するため、Rustベースのユーザー空間TCP実装であるsmoltcpを採用しました。パケットがローカルプロキシに到達すると、クライアントは変換処理を実行する必要がありました。すなわち、smoltcpを使用してL4ストリームをWireGuardトンネル用のL3パケットに変換したのです。
この方法は機能しましたが、効率的とは言えませんでした。Smoltcpは組み込みシステム向けに最適化されており、最新のTCP機能をサポートしていません。さらに、Cloudflareのエッジ側では、L3パケットをL4ストリームに戻す変換処理も必要でした。ユーザーにとって、これはパフォーマンスの頭打ちとして現れました。画像や動画のためにブラウザが数十の同時接続を開くメディアリッチなサイトでは、高性能なTCPスタックの欠如により、高速な光ファイバー接続環境であっても高遅延と読み込みの遅さが発生し、プロキシモードは他のすべてのデバイスクライアントモードと比べて著しく遅く感じられました。
QUICによる直接L4プロキシングの導入
この問題を解決するため、Cloudflare Oneクライアントのプロキシモードを一から再構築し、プロキシモードにおけるWireGuardの使用を廃止しました。これにより、QUICの機能を最大限に活用できるようになります。当社は既にIPパケットのプロキシングにMASQUE（QUICの一部）を活用しており、今回、直接L4プロキシングのためにQUICストリームの使用を追加しました。
CONNECTメソッドを伴うHTTP/3（RFC 9114）を活用することで、トラフィックを本来のレイヤー4で維持できるようになりました。ブラウザがクライアントにSOCKS5またはHTTPリクエストを送信しても、それはもはやL3パケットに分解されません。
代わりに、リクエストは直接QUICストリームにカプセル化されます。
このアーキテクチャの変更により、3つの直接的な技術的利点が得られます:
- smoltcpの回避: L3変換レイヤーを削除することで、IPパケット処理とsmoltcpのTCP実装に伴う制限を排除します。
- ネイティブQUICの利点: トランスポート層でネイティブに処理される、現代的な輻輳制御とフロー制御の恩恵を受けられます。
- 調整可能性: クライアントとCloudflareのエッジがQUICのパラメータを調整し、パフォーマンスを最適化できます。
内部テストでは結果は明らかで、ダウンロード/アップロード速度は2倍に、遅延は大幅に減少しました。
最も恩恵を受けるユースケース
高速化は常に歓迎されますが、このアップデートは特に以下の3つの主要なユースケースにおける課題を解決します。
第一に、サードパーティ製VPNとの共存シナリオです。特定のオンプレミスリソースに従来型VPNがまだ必要であったり、冗長性やコンプライアンスの観点からデュアルSASE構成が求められたりする場合、ローカルプロキシモードはWebトラフィックにゼロトラストセキュリティを追加するための定番ソリューションです。このアップデートにより、「セキュリティの重ね掛け」がユーザーエクスペリエンスの犠牲を意味しなくなります。
第二に、高帯域幅アプリケーションの分割です。プロキシモードは、特定のブラウザトラフィックだけをCloudflare Gateway経由に誘導し、OSのその他の通信はローカルネットワークに残すためによく使用されます。ユーザーはパフォーマンスを犠牲にすることなく、高解像度コンテンツのストリーミングや大規模データセットの処理を行えるようになります。
最後に、CLIツールやスクリプトでSOCKS5セカンダリリスナーに依存する開発者やパワーユーザーは、即座に改善を実感するでしょう。プロキシ経由のリモートAPI呼び出しやデータ転送も、Cloudflareグローバルネットワークの他の部分と同じ低遅延接続の恩恵を受けるようになります。
始め方
プロキシモードの改善は、Windows、macOS、Linuxデバイス向けの最小クライアントバージョン2025.8.779.0で利用可能です。これらのパフォーマンス向上を活用するには、最新版のCloudflare Oneクライアントを実行していることを確認してください。
- Cloudflare Oneダッシュボードにログインします。
- Teams & Resources > Devices > Device profiles > General profilesに移動します。
- 編集するプロファイルを選択するか、新規プロファイルを作成し、Service modeが「Local proxy mode」に、Device tunnel protocolが「MASQUE」に設定されていることを確認します。
クライアントマシンでアクティブなプロトコルは、ターミナルで以下のコマンドを実行して確認できます:
warp-cli settings | grep protocolデバイスのプロキシモードを有効にする詳細な手順については、当社のドキュメントをご覧ください。
まだSASEの導入を始めていない場合は、最大50ユーザーまで無料で利用できるCloudflare Oneアカウントに今すぐサインアップできます。アカウントを作成し、Cloudflare Oneクライアントをダウンロードして、オンボーディングガイドに従うだけで、チーム全体でより高速かつ安定した接続を体験できます。
原文を表示
When you need to use a proxy to keep your zero trust environment secure, it often comes with a cost: poor performance for your users. Soon after deploying a client proxy, security teams are generally slammed with support tickets from users frustrated with sluggish browser speed, slow file transfers, and video calls glitching at just the wrong moment. After a while, you start to chalk it up to the proxy — potentially blinding yourself to other issues affecting performance.
We knew it didn’t have to be this way. We knew users could go faster, without sacrificing security, if we completely re-built our approach to proxy mode. So we did.
In the early days of developing the device client for our SASE platform, Cloudflare One, we prioritized universal compatibility. When an admin enabled proxy mode, the Client acted as a local SOCKS5 or HTTP proxy. However, because our underlying tunnel architecture was built on WireGuard, a Layer 3 (L3) protocol, we faced a technical hurdle: how to get application-layer (L4) TCP traffic into an L3 tunnel. Moving from L4 to L3 was especially difficult because our desktop Client works across multiple platforms (Windows, macOS, Linux) so we couldn’t use the kernel to achieve this.
To get over this hurdle, we used smoltcp, a Rust-based user-space TCP implementation. When a packet hit the local proxy, the Client had to perform a conversion, using smoltcp to convert the L4 stream into L3 packets for the WireGuard tunnel.
While this worked, it wasn't efficient. Smoltcp is optimized for embedded systems, and does not support modern TCP features. In addition, in the Cloudflare edge, we had to convert the L3 packets back into an L4 stream. For users, this manifested as a performance ceiling. On media-heavy sites where a browser might open dozens of concurrent connections for images and video, and the lack of a high performing TCP stack led to high latency and sluggish load times when even on high-speed fiber connections, proxy mode felt significantly slower than all the other device client modes.
Introducing direct L4 proxying with QUIC
To solve this, we’ve re-built the Cloudflare One Client’s proxy mode from the ground up and deprecated the use of WireGuard for proxy mode, so we can capitalize on the capabilities of QUIC. We were already leveraging MASQUE (part of QUIC) for proxying IP packets, and added the usage of QUIC streams for direct L4 proxying.
By leveraging HTTP/3 (RFC 9114) with the CONNECT method, we can now keep traffic at Layer 4, where it belongs. When your browser sends a SOCKS5 or HTTP request to the Client, it is no longer broken down into L3 packets.
image
Instead, it is encapsulated directly into a QUIC stream.
This architectural shift provides three immediate technical advantages:
Bypassing smoltcp: By removing the L3 translation layer, we eliminate IP packet handling and the limitations of smoltcp’s TCP implementation.
Native QUIC Benefits: We benefit from modern congestion control and flow control, which are handled natively by the transport layer.
Tuneability: The Client and Cloudflare’s edge can tune QUIC’s parameters to optimize performance.
In our internal testing, the results were clear: download and upload speeds doubled, and latency decreased significantly.
Who benefits the most
While faster is always better, this update specifically unblocks three key common use cases.
First, in coexistence with third-party VPNs where a legacy VPN is still required for specific on-prem resources or where having a dual SASE setup is required for redundancy/compliance, the local proxy mode is the go-to solution for adding zero trust security to web traffic. This update ensures that "layering" security doesn't mean sacrificing the user experience.
Second, for high-bandwidth application partitioning, proxy mode is often used to steer specific browser traffic through Cloudflare Gateway while leaving the rest of the OS on the local network. Users can now stream high-definition content or handle large datasets without sacrificing performance.
Finally, developers and power users who rely on the SOCKS5 secondary listener for CLI tools or scripts will see immediate improvements. Remote API calls and data transfers through the proxy now benefit from the same low-latency connection as the rest of the Cloudflare global network.
How to get started
The proxy mode improvements are available with minimum client version 2025.8.779.0 for Windows, macOS, and Linux devices. To take advantage of these performance gains, ensure you are running the latest version of the Cloudflare One Client.
Log in to the Cloudflare One dashboard.
Navigate to Teams & Resources > Devices > Device profiles > General profiles.
Select a profile to edit or create a new one and ensure the Service mode is set to Local proxy mode and the Device tunnel protocol is set to MASQUE.
You can verify your active protocol on a client machine by running the following command in your terminal:
warp-cli settings | grep protocol
Visit our documentation for detailed guidance on enabling proxy mode for your devices.
If you haven't started your SASE journey yet, you can sign up for a free Cloudflare One account for up to 50 users today. Simply create an account, download the Cloudflare One Client, and follow our onboarding guide to experience a faster, more stable connection for your entire team.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み