Cloudflare Tunnelで公開しているWordPressに「Error 1033: Cloudflare Tunnel error」と表示され、外部からアクセスできなくなることがあります。サーバーを再起動した後、cloudflaredを更新した後、社内ネットワークやファイアウォールを変更した後に起こりやすいエラーです。
Error 1033は、Cloudflareネットワークがトラフィックを渡せる正常なcloudflaredコネクターを見つけられない状態です。WordPressのPHPやデータベースを調べる前に、Tunnelの状態、cloudflaredサービス、ホストの稼働、DNS、外向き7844番ポートを確認します。
ログを保存せず、cloudflaredの削除・再登録やTunnelの作り直しから始めないでください。資格情報、DNSルート、サービス設定まで変わり、元の停止原因が分からなくなります。現在の状態と時刻を残し、停止した一段だけを直します。
先に結論：Error 1033は8段階で確認する
- エラーURL、時刻、Ray ID、画面全体を保存する
- CloudflareのNetworking > Tunnelsで対象Tunnelの状態を確認する
- Healthy・Inactive・Down・Degradedのどれかを記録する
- cloudflaredのサービス・プロセスとホストの稼働を確認する
- 停止前後のcloudflaredログを保存する
- DNS解決と外向き7844番のUDP・TCPを確認する
- 原因箇所だけを修正し、TunnelがHealthyへ戻るか確認する
- WordPress、管理画面、SSL、外部連携、再発の有無を確認する
Tunnel自体は接続済みで、cloudflaredからローカルのWordPressへ届かない場合は1033ではなく502になることがあります。画面が502なら、WordPressの502 Bad Gatewayを直す確認順も使い、Tunnelの外側と内側を分けてください。
Cloudflare Error 1033とは？
Cloudflare公式のError 1033では、Cloudflareネットワークがトラフィックを受け取れる正常な`cloudflared`インスタンスを見つけられず、TunnelがCloudflareへ接続されていない状態と説明されています。
Cloudflare Tunnelでは、オリジンサーバー側のcloudflaredがCloudflareへ外向き接続を作ります。閲覧者からサーバーへ直接ポートを公開しなくても、Cloudflareから既存のTunnelを通してWordPressへ到達できます。したがってcloudflaredが停止すると、Cloudflareは接続先を失います。
1033の時点では、要求がローカルのNginx、Apache、PHP、WordPressへ届いていない場合があります。WordPressのログに記録がないことだけで、WordPressが壊れたとは判断できません。Tunnel状態とcloudflaredログを優先します。
1033とTunnel経由の502の違い
| 表示 | 接続が止まる場所 | 最初に見る場所 |
|---|---|---|
| Error 1033 | Cloudflareとcloudflaredの間 | Tunnel状態、cloudflared、ネットワーク |
| Tunnelの502 | cloudflaredとローカルサービスの間 | ingressのURL、プロトコル、ポート、WordPress側 |
| Cloudflare 523 | 通常のオリジンIPへの経路 | DNSのIP、ルーティング、ファイアウォール |
| Cloudflare 522 | 通常のオリジンへの接続待ち | 負荷、遮断、経路、接続応答 |
Cloudflare Tunnelの公式トラブルシューティングでも、1033はTunnelがCloudflareへ未接続、502はTunnel接続後にcloudflaredがローカルのオリジンサービスへ届かない状態として区別されています。
Cloudflare Tunnelを使わず、通常のDNSレコードでオリジンIPへ接続しているサイトでは、523や522の確認が中心です。Cloudflare 523の確認手順とCloudflare 522の確認手順を使い分けてください。
Tunnelの4つの状態を読み分ける
| 状態 | 意味 | 優先する確認 |
|---|---|---|
| Healthy | Tunnelが稼働し、Cloudflareへ接続 | 1033が続くなら対象ホスト・Tunnel違いを確認 |
| Inactive | 作成済みだがコネクターが一度も接続していない | cloudflaredのインストールと起動 |
| Down | 以前は接続したが現在は停止 | サービス、ホスト停止、直前の変更 |
| Degraded | 稼働中だが一部接続に失敗 | ログ、ファイアウォール、接続先IP・ポート |
Cloudflare公式ではHealthyなTunnelがグローバルネットワークへ複数接続を持つと説明しています。Degradedは完全停止ではありませんが、接続がさらに失われるとDownになる可能性があります。表示できている間にログとネットワーク変更を確認します。
WordPressでError 1033が出る主な原因
1．cloudflaredサービスが停止している
OS再起動後に自動起動しなかった、更新でサービス設定が変わった、プロセスが異常終了した、手動実行のターミナルを閉じたなどでcloudflaredが停止します。TunnelがDownなら最初にサービスとプロセスの状態を確認します。
2．cloudflaredを動かすホストが停止・切断している
サーバー、NAS、仮想マシン、コンテナ、社内PCなど、コネクターを動かす機器自体が停止している場合があります。電源、OS、ネットワークインターフェース、デフォルトゲートウェイ、時刻同期を確認します。
3．DNSでTunnel接続先を発見できない
cloudflaredはCloudflare Tunnelの接続先をDNSで発見します。ローカルDNSがSRVレコードを処理できない、社内DNSが遮断する、コンテナ内のDNSが応答しない場合、ログにedge discoveryやDNS query failedといった記録が残ります。
4．外向きUDP 7844番が遮断されている
cloudflaredがQUICでCloudflareへ接続する際は、外向きUDP 7844番を使います。ファイアウォール、セキュリティグループ、社内プロキシの変更後にQUICハンドシェイクがタイムアウトすることがあります。
5．TCP 7844番も遮断され、HTTP/2へ切り替えられない
Cloudflare公式によると、QUIC接続が失敗するとcloudflaredはHTTP/2 over TCPへ自動的に切り替えます。しかし外向きTCP 7844番も遮断されていると、どちらのプロトコルでもCloudflareへ到達できず、TunnelがDownになります。
6．資格情報・トークン・設定ファイルが読めない
サービス実行ユーザーの変更、ファイル移動、権限変更、コンテナ再作成などで、cloudflaredが資格情報や設定ファイルを読めなくなる場合があります。ファイルを公開共有せず、ログに表示されたパスとサービスの実行ユーザーを確認します。
7．古いcloudflaredや更新失敗が残っている
Cloudflareのトラブルシューティングは、多くの問題がcloudflaredの最新版への更新で解決すると案内しています。ただし本番で即時更新する前に、現在のバージョン、変更履歴、対応OS、ロールバック方法を確認します。更新後はサービス状態とログを確認します。
8．対象ホストが別のTunnelや削除済みルートを参照している
複数Tunnelを運用していると、調べているTunnelはHealthyでも、問題の公開ホストが別のDown状態のTunnelへ向いていることがあります。公開ホスト名、DNSルート、Tunnel ID、コネクター名を対応させます。
変更前に保存する情報
- Error 1033の画面、URL、Ray ID、時刻、タイムゾーン
- 対象の公開ホスト名とTunnel名・ID
- Healthy・Inactive・Down・Degradedの現在状態
- cloudflaredのバージョン、実行方法、サービス状態
- 停止前後のcloudflaredログ
- コネクターを動かすホスト、OS、コンテナの稼働状態
- 直前の再起動、更新、DNS、ファイアウォール変更
- 複数コネクターやレプリカの有無
ログや設定を共有するときはTunnelトークン、証明書、秘密鍵、APIトークン、内部の認証情報を隠します。Tunnelトークンを知る第三者はコネクターを起動できる可能性があるため、公開掲示板や画像へ載せてはいけません。
Tunnel状態とログで停止場所を確認する
CloudflareダッシュボードのNetworking > Tunnelsで、対象ホストに対応するTunnelを開きます。コネクターが複数ある場合は、全体がDownなのか、一部だけDegradedなのかを確認します。表示名だけでなくTunnel IDも照合します。
次に、cloudflaredを動かすホストでサービスとプロセスを確認します。管理権限が必要な操作は、サーバーのOSと導入方法に合う公式手順を使います。見慣れないコマンドを本番へ貼り付ける前に、管理者へ確認してください。
ログでは、最初に現れたエラーと、その直前のネットワーク・認証・停止メッセージを見ます。再試行メッセージだけを追うのではなく、DNS resolution、QUIC、TCP、credential、permissionなどの語と時刻を確認します。
| ログの傾向 | 疑う場所 | 次の確認 |
|---|---|---|
| edge discovery・DNS query failed | ローカルDNS | SRV応答、リゾルバー、UDP 53 |
| Failed to dial a quic connection | UDP経路 | 外向きUDP 7844、FW |
| DialContext・TCP timeout | TCP経路 | 外向きTCP 7844、経路 |
| credential・permission | 資格情報と実行ユーザー | ファイルパス、権限、サービス設定 |
| process stopped・crash | cloudflared・OS | サービス、更新、メモリ、再起動履歴 |
公式のTunnelトラブルシューティングでは、DNS解決失敗、QUICのUDP 7844番、HTTP/2のTCP 7844番をログから区別する具体例が示されています。自分のログに一致する段だけを確認します。
原因別の安全な直し方
1．Inactiveなら正しいコネクターを導入・起動する
InactiveはTunnelを作成したものの、cloudflaredが一度も接続していない状態です。Cloudflareダッシュボードで対象Tunnelを選び、OSに合う公式の導入手順を確認します。別Tunnelのトークンを使わないよう、Tunnel IDを照合します。
2．Downならサービスとホストを復旧する
以前は接続していたDownでは、cloudflaredサービス、サーバー電源、仮想マシン、コンテナ、ネットワークを確認します。再起動する前にログを保存し、停止理由が更新、権限、メモリ、ネットワークのどれかを確認します。
サービスを再起動してHealthyに戻っても、原因を記録しなければ再発します。自動起動設定、監視、ログ保存、ホストのリソース不足まで確認してください。
3．Degradedなら失敗した接続だけを調べる
Degradedでもトラフィックを処理できる場合があります。稼働中の接続を全停止せず、失敗したコネクター、接続先IP、プロトコル、時刻をログで確認します。複数レプリカがあれば、問題のホストやネットワークを分けます。
4．DNS解決をローカルホストで確認する
DNSエラーがある場合は、cloudflaredを実際に動かしているホストまたはコンテナから、公式が示すTunnel接続先のSRVレコードを確認します。別のPCで解決できても、コンテナ内や社内DNSだけ失敗していることがあります。
ローカルDNSだけが失敗する場合は、リゾルバー、`resolv.conf`、DockerやKubernetesのDNS、外向きUDP 53番の遮断を管理者と確認します。公開DNSへ無断変更すると社内名前解決へ影響するため、環境の方針に従います。
5．UDP・TCP 7844番の外向き通信を許可する
QUICのタイムアウトなら外向きUDP 7844番、TCPタイムアウトなら外向きTCP 7844番を確認します。Cloudflareが案内するTunnelの宛先IP範囲とポートだけに限定し、受信ポートを広く公開する必要はありません。
UDPを許可できない環境ではcloudflaredがHTTP/2へ自動フォールバックします。ただしTCP 7844番まで閉じていれば接続できません。プロトコルを強制する前に、ネットワーク方針とログのフォールバック記録を確認します。
6．cloudflaredを計画的に更新する
古いバージョンならCloudflare公式の更新手順と変更履歴を確認します。本番更新前に、現在版、設定ファイル、サービス定義、ロールバック手順を保存します。更新後はバージョン、サービス自動起動、Tunnel状態、ログを確認します。
7．資格情報のパスと実行ユーザーを合わせる
設定ファイルやcredentials-fileが見つからない場合は、cloudflaredサービスがどのユーザーで動き、どのパスを参照しているかを確認します。ファイル権限を無条件で緩めず、必要なサービスユーザーだけが読める状態にします。
やってはいけない対処
- ログを保存せずサービス再起動だけを繰り返す
- Tunnel、DNSルート、コネクターを一度に削除して作り直す
- Tunnelトークンや資格情報を公開掲示板へ貼る
- 原因不明のままファイアウォールを全開放する
- 外向き通信の問題なのに受信ポートをインターネットへ公開する
- 別Tunnelのトークンでコネクターを起動する
- 設定ファイルの権限を誰でも読める状態にする
- WordPressのDB初期化や再インストールから始める
Cloudflare Tunnelの利点の一つは、オリジンへ直接の受信ポートを公開せず接続できることです。1033を直すためにルーターやサーバーの受信ポートを広く開けると、本来の防御設計を崩します。
復旧後の確認項目
- 対象TunnelがHealthyになり、全コネクター状態を確認した
- トップ、投稿、固定ページが外部回線から開く
- `/wp-admin/`へログインし、保存と画像アップロードができる
- 証明書、HTTPS、www有無の転送が正常
- REST API、フォーム、Webhook、Cronが動く
- ローカルオリジンへ余計な受信ポートを開けていない
- cloudflaredの自動起動、監視、ログ保存が動く
- 一定時間後とホスト再起動後も1033が再発しない
TunnelがHealthyなのにWordPressへ届かない場合は、ingressのサービスURL、`http`と`https`、ポート、ローカルサービスの待受を確認します。この段階で502が出るなら、問題はcloudflaredとWordPressの間へ移っています。
検索への影響と復旧後の対応
GoogleのHTTPステータス資料では、5xxが返るとクロール速度が落ち、継続するとURLがインデックスから外れ得ることが説明されています。1033画面の実際のHTTPステータスと継続時間を記録します。
短時間で復旧した場合は、主要URLの200応答とサイトマップ取得を確認します。長時間続いた場合は、Search Consoleのクロール統計、ページのインデックス登録、主要URLの検査を順に確認します。エラーが残るURLだけを優先します。
それでも直らないときの問い合わせ情報
- 対象ホスト、Error 1033画面、Ray ID、発生時刻
- Tunnel名・IDとHealthy・Inactive・Down・Degradedの状態
- cloudflaredのバージョン、OS、導入方法
- 認証情報を除いた停止前後のログ
- ホスト、仮想マシン、コンテナの稼働状態
- DNS、UDP 7844、TCP 7844の確認結果
- 直前の再起動、更新、FW、ネットワーク変更
- 複数コネクターやレプリカの構成
ホスティング会社や社内ネットワーク管理者には、外向き7844番のUDP・TCPと宛先範囲を確認したいことを伝えます。CloudflareへはTunnel ID、状態、時刻、機密情報を除いたログを渡すと切り分けしやすくなります。
よくある質問
cloudflaredを再起動すれば直りますか？
一時的なプロセス停止なら戻る場合があります。ただしDNS、7844番遮断、資格情報、古いバージョンが原因なら再発します。再起動前にログを保存し、再起動後も原因と自動起動を確認してください。
ポート443を開ければ直りますか？
1033の第一確認はcloudflaredからCloudflareへの外向き7844番です。オリジンの受信443番をインターネットへ広く開けることは、Tunnelの復旧条件ではありません。環境のネットワーク方針に従ってください。
TunnelがHealthyなのに1033が出るのはなぜですか？
確認しているTunnelと、問題の公開ホストが参照するTunnelが異なる可能性があります。公開ホスト、DNSルート、Tunnel IDを照合します。反映待ちや一部コネクターだけの断続障害も、時刻を合わせて確認します。
WordPressのデバッグはいつ行いますか？
TunnelがHealthyに戻り、要求がローカルサービスへ届いた後もWordPressだけで問題が続くときです。バックアップまたはテスト環境を用意し、WordPress公式のデバッグ手順に従い、本番画面へログを表示し続けないようにします。
まとめ
Cloudflare Error 1033は、Cloudflareネットワークが正常なcloudflaredコネクターを見つけられず、Tunnelを通してWordPressへ要求を渡せない状態です。最初にTunnelの状態を読み、Inactive、Down、Degradedの意味に沿って確認します。
現在のログを保存し、cloudflaredサービス、ホスト、DNS、外向きUDP・TCP 7844番、資格情報の順に一項目ずつ調べてください。Tunnelを作り直す前に停止した段を直し、Healthy復帰、WordPress表示、防御設計、自動起動まで確認すれば、安全に再発防止へつなげられます。