知られている制限
以下に、Cloudflare WARPと互換性のないデバイス、ソフトウェア、および構成に関する情報を示します。
WARPクライアントはWindows Serverでは動作しません。サポートされているオペレーティングシステムのリストについては、ダウンロードページを参照してください。
管理ネットワーク検出は、Windows Server 2012 R2のIIS 8.5から提供されるTLS証明書では機能しません。この制限を回避するには、証明書を別のホストに移動してください。
WARPクライアントは、単一のWindowsデバイス上で複数のユーザーをサポートしていません。WARPは設定やキーを保存するためにハードコーディングされたグローバルパスを使用し、ユーザーごとに情報を保存しません。したがって、1人のユーザーがWARPにログインすると、その設定はデバイスからのすべてのトラフィックに適用されます。
DoHモードのゲートウェイにあるWindowsデバイスでは、nslookupはデフォルトでIPv6経由でWARPローカルDNSプロキシにDNSリクエストを送信します。しかし、WARPはIPv4マッピングされたIPv6アドレスを使用しているため（実際のIPv6アドレスではなく）、nslookupはこのアドレスタイプを認識せず、クエリは失敗します：
C:\Users\JohnDoe>nslookup google.comServer: UnKnownAddress: ::ffff:127.0.2.2
*** UnKnown can't find google.com: No response from serverこの問題を回避するには、クエリでWARPローカルDNSプロキシのIPv4アドレスを指定します：
C:\Users\JohnDoe>nslookup google.com 127.0.2.2または、Powershellを使用します：
PS C:\Users\JohnDoe> Resolve-DnsName -Name google.comWARPクライアントがローカルDNSプロキシをインスタンス化する方法のため、IPv6が有効な4G/5Gセルラーアダプタとは互換性がありません。これらのデバイスでWARPを実行するには、システムでIPv6を無効にする必要があります。
ComcastのDNSトラフィック（以下のIPへのトラフィック）はWARPを通じてプロキシされることはできません。これは、Comcastがユーザーのデバイスから直接送信されていないDNSトラフィックを拒否するためです。
- IPv4アドレス:
75.75.75.75と75.75.76.76 - IPv6アドレス:
2001:558:feed::1と2001:558:feed::2
この問題を回避するには、次のいずれかを行うことができます：
- 上記のIPをWARPから除外するスプリットトンネルルールを作成します。
- デバイスまたはルーターを設定して、
1.1.1.1↗のようなパブリックDNSサーバーを使用します。
上記のComcast DNSサーバーの制限と同様に、Cox DNSサーバーはWARPの出口IP（またはCox IPでない任意のIP）からのトラフィックに応答しません。回避策はほぼ同じですが、Cox DNSサーバーは個々のエンドユーザーに特有である可能性があります。次のいずれかを行うことができます：
- すべてのCox DNSサーバーを除外するスプリットトンネルルールを作成します。ビジネス顧客の場合は、COXのドキュメント ↗を参照してDNSサーバーのIPを確認してください。家庭用顧客の場合は、ローカルDNSサーバーを確認してください。家庭用DNSサーバーは通常、
68.105.28.0/24および68.105.29.0/24に該当します。 - デバイスまたはルーターを設定して、
1.1.1.1↗のようなパブリックDNSサーバーを使用します。
HP Velocityドライバーにはバグがあり、WARPを実行しているデバイスでブルースクリーンエラーを引き起こす可能性があります。HPはこのドライバーをアンインストールすることを推奨しています ↗。
Cisco Merakiデバイスには、WARPトラフィックが時折Statistical-P2P ↗として識別され、優先度が下げられたり完全にドロップされたりするバグがあります。この問題を解決するには、Cisco MerakiデバイスでStatistical-P2Pを無効にしてください。
Windows Teredo ↗インターフェースはWARPクライアントと競合します。TeredoとWARPがIPv6トラフィックのルーティング制御を争うため、WindowsデバイスでTeredoを無効にする必要があります。これにより、WARPクライアントがデバイス上でIPv6接続を提供できるようになります。
現在、Linux上のDocker ↗は、WARPに必要な基盤となるネットワークトンネルMTUの変更を行いません。これにより、ホストマシンでWARPが有効になっている場合、Dockerコンテナ内で接続の問題が発生する可能性があります。たとえば、curl -v https://cloudflare.com > /dev/nullは、デフォルトのブリッジネットワークドライバーを使用しているDockerコンテナから実行すると失敗します。
Dockerがこの動作を変更するまで、Linux上のWARP + DockerユーザーはDockerのネットワークインターフェースのMTUを手動で再構成できます。次のいずれかを行うことができます：
/etc/docker/daemon.jsonを修正して次の内容を含める：
{ "mtu": 1420}または、動作するMTU値を持つDockerネットワークを作成します：
docker network create -o "com.docker.network.driver.mtu=1420" my-docker-networkMTU値は、ホストのデフォルトインターフェースのMTUからWARPプロトコルのオーバーヘッドの80バイトを引いた値に設定する必要があります。ほとんどのMTUは1500であるため、1420はほとんどの人にとって機能するはずです。