「WARP をつないでいるときだけ、つながらないんだけど…」
情シスをやっていると、こういう問い合わせは季節の風物詩みたいに届きます。そのたびに僕がやっている調査コマンドを、この機会に一覧にしてみました。Windows の PowerShell で使うものが中心です（Cloudflare WARP は、いまの正式名称だと Cloudflare One Client）。Macみたいな格好いいものはうちの現場では使えません(笑)。Windows一択！
左端のコマンドは、横のボタンでそのままコピーできます。調査中は手が汚れ…ではなく、気持ちに余裕がないので、コピペで済むのがいちばんです。
表の見かた ✔ が付いたコマンドは、2026年10月時点で Cloudflare の公式ドキュメントに載っていることを確認したものです。付いていないものは、バージョンや管理ポリシーで使えるサブコマンドや出力が変わることがあります。迷ったら
warp-cli --helpで確かめてください。
まず結論：調べる順番はこれ
おなかがすいていると、つい最初から一番重いコマンドに手を出したくなります。でも、順番はこうです。
- 接続状態と、いま適用されている設定
- ネットワークの判定とルーティング
- DNS と通信経路
- 詳細ログ（再現できるときだけ）
まずは「読むだけ」のコマンドで原因を絞ります。設定を変えるのは、いちばん最後です。
1. 接続状態と設定を見る
| コマンド | 何がわかる？ | こんなときに |
|---|---|---|
warp-cli status |
WARP がつながっているか（Connected / Disconnected など） | まずはここ。つながっていなければ話が早い |
warp-cli settings ✔ |
端末に実際に適用されている設定（動作モードなど） | Split Tunnel、接続モード、DNS 設定の確認 |
warp-cli -l status ✔ |
接続状態の変化をリアルタイムで表示 | つながるまでの途中で、どこで止まるのかを見たいとき |
warp-cli debug alternate-network ✔ |
現在のネットワークの判定に使う情報（Managed Networks の TLS エンドポイント作成にも使う） | 社内や自宅で、ネットワーク判定が思った通りか確認 |
warp-cli --version |
クライアントのバージョン | 「あの人だけ挙動が違う」の原因がバージョン差かを確認 |
warp-cli --help |
使えるコマンドの一覧 | そのバージョンで使えるサブコマンドの確認 |
特に大事なのは warp-cli settings です。管理画面で設定したつもりでも、端末に届いていなければ何も変わりません。「設定したのに効かない」の半分くらいは、ここで答えが出ます。
2. 詳細ログを集める
| コマンド | 何がわかる？ | こんなときに |
|---|---|---|
warp-diag ✔ |
診断情報を ZIP にまとめる（Windows ではデスクトップに保存） | サポートへの問い合わせや、後で見返すための証拠集め |
warp-diag --enable-all-routes ✔ |
Split Tunnel に設定した全 IP・ドメインのルーティングテストも含める | 特定の宛先だけ通らないときの調査 |
warp-cli debug extra start ✔ |
詳細デバッグログの採取を開始 | DNS やトンネルの一時的な不調を追いたいとき |
warp-cli debug extra reconnect ✔ |
詳細ログの採取中にトンネルを再接続 | 接続失敗を再現して、そのときのログを取りたいとき |
warp-cli debug extra stop ✔ |
詳細ログの採取を止める | 再現テストが終わったら、すぐ止める |
warp-diag の ZIP の中身は、daemon.log（いちばん詳しいログ）、warp-status.txt（接続状態）、warp-settings.txt（適用されている設定）あたりを見れば足ります。
debug extra は便利ですが、食べ放題のノリで使うと痛い目にあいます。
- クライアント 2026.5.0 以降で使えます
- 10 分たつと自動で終わります
- Windows だと 10 分で 600 MB 以上になることがあります（ほとんどは
netshの TCPIP トレースです）
障害を再現している間だけ使うのがコツです。
3. DNS（名前解決）を見る
| コマンド | 何がわかる？ | こんなときに |
|---|---|---|
Resolve-DnsName example.com |
OS が使う DNS 経路での名前解決の結果 | WARP 接続中に名前が引けているか |
Resolve-DnsName example.com -Server 8.8.8.8 |
指定した DNS サーバーに聞いたときの結果 | OS 標準の結果と見比べたいとき |
nslookup example.com |
DNS の問い合わせ結果 | 応答の速さやタイムアウトを見たいとき |
ipconfig /all |
NIC ごとの IP、DNS、ゲートウェイ | WARP の仮想 NIC と物理 NIC の設定を見比べる |
Get-DnsClientServerAddress |
Windows が認識している DNS サーバー | DNS サーバーの設定に差がないか |
Get-DnsClientNrptPolicy |
NRPT（ドメイン別の名前解決ルール）の一覧 | 特定のドメインだけ違う DNS に行く理由を探すとき |
ひとつ注意です。-Server 8.8.8.8 のように DNS を指定して聞いても、それが「WARP 経由と非経由の比較」になるとは限りません。Split Tunnel や DNS の処理順で道が変わるので、次の通信テストと合わせて見てください。
4. トンネルと通信経路を見る
| コマンド | 何がわかる？ | こんなときに |
|---|---|---|
curl.exe -s https://www.cloudflare.com/cdn-cgi/trace ✔ |
Cloudflare から見た、こちらの接続情報 | warp=on で、WARP 経由かどうかを確認 |
Test-NetConnection example.com -Port 443 |
TCP 443 でつながるか | HTTPS の不調が、TCP の手前で起きているか |
tracert example.com |
経路のホップと応答時間 | 通信経路のおおまかな様子を見る |
route print |
Windows のルーティングテーブル | 思わぬゲートウェイや、ルートの優先順位の確認 |
Get-NetRoute -AddressFamily IPv4 |
IPv4 ルートの一覧 | 宛先ごとのルートとメトリックを見る |
Get-NetAdapter |
ネットワークアダプターの状態 | WARP の仮想 NIC や物理 NIC が有効か |
cdn-cgi/trace は WARP の通り道を確認するのに便利です。ただ、Include モードでは、宛先が Include リストに入っていないと warp=off になります。warp=off と出ただけで「WARP が悪い」と決めつけないでください。
5. Windows のサービスとログを見る
| コマンド | 何がわかる？ | こんなときに |
|---|---|---|
Get-Service *Cloudflare* |
Cloudflare 関連サービスの状態 | サービスが止まっていないか、起動に失敗していないか |
Get-Process *warp* |
WARP 関連のプロセス | そもそも動いているか |
Get-ChildItem 'C:\ProgramData\Cloudflare' -Recurse -File |
Cloudflare のログなどのファイル一覧 | warp-diag の ZIP 以外のログを探すとき |
Get-Content 'C:\ProgramData\Cloudflare\daemon.log' -Tail 200 |
ログの末尾 200 行 | 直近のエラーを見たいとき |
ログの置き場所はバージョンで変わるかもしれません。まず一覧を見て、あるものを読むようにしてください。
僕のやらかしと、いまの調べ方
昔の僕は、「つながらない」と聞いたら、まず詳細ログを取っていました。気合いだけは満点でした。
でも、600 MB 以上のデータが手元に溜まって、読む気力もなくなって、結局原因は設定の見落とし。そういうことがありました。
DNS だけを見て「名前は引けているから大丈夫」と決めつけて、通信経路を見ていなかったこともあります。cdn-cgi/trace で warp=on なのに、特定のサイトだけ開かなかったときは、原因は Split Tunnel の設定でした。ルーティングを見るまで気づけなかったんです。
今は、次の流れに落ち着いています。「WARP につないでいるときだけ、特定のサイトに入れない」という場合の例です。
Step 1：接続状態と設定
warp-cli status
warp-cli settings
つながっているか、どのモードか、Split Tunnel や DNS の設定はどうか、を見ます。ここで半分くらいは見当がつきます。
Step 2：ネットワークの判定とルート
warp-cli debug alternate-network
route print
つないでいるネットワークが想定通りに判定されているか、Windows のルートに変なところがないかを確認します。
Step 3：DNS と通信経路
Resolve-DnsName example.com
Test-NetConnection example.com -Port 443
curl.exe -s https://www.cloudflare.com/cdn-cgi/trace
名前解決、TCP の接続、WARP の通り道を、それぞれ別々に切り分けます。
Step 4：詳細ログ（本当に必要なときだけ）
warp-cli debug extra start
# ここで不具合を再現する
warp-cli debug extra stop
warp-diag
ここまで来るのは、Step 3 までで分からなかったときだけです。始めた時刻と、起きた現象をメモしておくと、あとでログと突き合わせやすくなります。
調べるときの心得
- 設定を変えるコマンドは最初に打たない。 まず読むだけのコマンドで様子を見ます。原因が見えてからでも遅くありません。
- DNS の比較は道を意識する。 DNS サーバーを指定して聞くだけでは、WARP の DNS 処理全体は確かめられません。
- ログにはいろいろ入っている。 IP アドレス、ホスト名、ユーザー名などです。社外に出す前に、中身を見ておきましょう。
- 時刻をメモする。
warp-diagは、不具合を再現した直後に取ると、ログと突き合わせやすくなります。
まとめ
- 最初の一歩は
warp-cli status、warp-cli settings、warp-cli debug alternate-networkの3つ - DNS と通信経路は、Windows 標準のコマンドと
cdn-cgi/traceで、別々に切り分ける - 詳細ログ（
debug extraとwarp-diag）は最後の手段。10 分で終わるし、Windows だとデータもでかい
調べものが終わったら、ちゃんとごはんを食べましょう。空腹で調査すると、だいたい判断を誤ります。
参考
- Cloudflare One Client の診断ログ（Cloudflare Docs）
- 接続ステータス（Cloudflare Docs）
- Managed networks（Cloudflare Docs）
ITもごはんも、腹八分目が長続きのコツ！
コメント