VPS + Caddy + WordPress を構成するさようならCloudflare Tunnel

2026年3月2日

脱Cloudflare Tunnel計画で、VPSで入れているCloudflareをCaddyに置き換えようとしている。

前提

構成

構成はこんな感じ。なんか最近AIが秒で書いてくれて地味に助かる。

graph TD subgraph Internet[インターネット] User((ユーザー)) end subgraph VPS[Ubuntu VPS] direction TB subgraph CaddyServer[Caddy / ポート: 80, 443] Caddy[Caddy] end subgraph DockerNetwork[Docker ネットワーク] WP[WordPress Container] end end %% 通信の流れ User -- HTTPS:443 --> Caddy Caddy -- reverse_proxy<br/>localhost:内部ポート --> WP %% 役割の説明 style Caddy fill:#f9f,stroke:#333,stroke-width:2px style WP fill:#0073aa,stroke:#fff,stroke-width:2px,color:#fff style VPS fill:#f5f5f5,stroke:#333,stroke-dasharray: 5 5 note1[SSL証明書の自動管理<br/>圧縮: encode zstd gzip] -.-> Caddy

ConoHa VPS 2GB RAM
Ubuntu 24.04.3
caddy v2.10.2

DNSの設定

ダウンタイムとかどうでもいいので、しれっと既存のレコードを削除して新たにAレコード追加する。

dig 独自ドメイン
dig 独自ドメイン @8.8.8.8

dig 独自ドメイン
dig 独自ドメイン @8.8.8.8

次の設定をしながら反映されるのを待つ……とか思ってたら秒で反映されてびっくりした。

Caddyの設定

独自ドメイン {
    reverse_proxy localhost:ポート

    # 圧縮
    encode zstd gzip

    log {
        output file /var/log/caddy/独自ドメイン.access.log
    }
}

独自ドメイン {
    reverse_proxy localhost:ポート

    # 圧縮
    encode zstd gzip

    log {
        output file /var/log/caddy/独自ドメイン.access.log
    }
}

フォーマットする。

sudo caddy fmt --overwrite /etc/caddy/Caddyfile

sudo caddy fmt --overwrite /etc/caddy/Caddyfile

検証する。ログファイルの権限がcaddyのみなのでsudoつける。

sudo caddy validate --config /etc/caddy/Caddyfile

sudo caddy validate --config /etc/caddy/Caddyfile

実行する。

sudo systemctl reload caddy

sudo systemctl reload caddy

ログ見る。

sudo journalctl -u caddy -f

sudo journalctl -u caddy -f

いつ見ても覚えづらいsystemd系統のコマンド。

ログファイルのパーミッションに注意

ログファイルは基本的にcaddyの権限となるのだが、エラーが出ていたらだいたいrootユーザになってしまっている。ユーザをなおせば大丈夫

sudo chown caddy:caddy /var/log/caddy/ログファイル

sudo chown caddy:caddy /var/log/caddy/ログファイル

（やってない）ヘッダ偽装しろという指示もあり

最初Geminiに聞いたときは、リバースプロキシするなら以下のようにヘッダかけと言われた。

独自ドメイン {
    # ログを出力（トラブルシューティングに便利）
    log {
        output file /var/log/caddy/独自ドメイン.access.log
    }

    # WordPressへのリバースプロキシ
    reverse_proxy localhost:ポート {
        # WordPressが正しいURLを生成するために必要なヘッダー
        header_up Host {host}
        header_up X-Real-IP {remote_host}
        header_up X-Forwarded-For {remote_host}
        header_up X-Forwarded-Proto {scheme}
    }

    # セキュリティ向上のための圧縮
    encode gzip
}

独自ドメイン {
    # ログを出力（トラブルシューティングに便利）
    log {
        output file /var/log/caddy/独自ドメイン.access.log
    }

    # WordPressへのリバースプロキシ
    reverse_proxy localhost:ポート {
        # WordPressが正しいURLを生成するために必要なヘッダー
        header_up Host {host}
        header_up X-Real-IP {remote_host}
        header_up X-Forwarded-For {remote_host}
        header_up X-Forwarded-Proto {scheme}
    }

    # セキュリティ向上のための圧縮
    encode gzip
}

しかし今までCloudflare Tunnelでこんな設定してなかったけどなぁと思い、設定せずにやったところ、普通に動く。しかしGeminiは「いやheader_up Host {host}だけでも書きなよ」とのことだが、しかし動いているしなぁと思った。

Claudeに聞いたところ、「Caddyのreverse_proxyディレクティブは、何も指定しなくても以下のヘッダーを自動的に設定します」とのことだった。

X-Forwarded-For: クライアントのIPアドレス
X-Forwarded-Proto: スキーム（http/https）
X-Forwarded-Host: オリジナルのHostヘッダー

これらは標準的なリバースプロキシのヘッダーで、Caddyが「気を利かせて」自動設定している、のだとさ。

Hostヘッダーに関しては、Caddyはデフォルトでプロキシ先（バックエンド）のアドレスに設定するので、Geminiの言う通りこれは設定しないとlocalhost:ポート番号に渡されるらしい。が、これについてはWordPress側の設定でURLを定義しているので、Hostヘッダに関係なくURL生成されているんだろうね、とのこと。

なので、マルチサイト構成とかで複数ドメイン使う場合や、なんかプラグインとかで参照する必要があるならちゃんと設定した方がいいよ、でも動いているならシンプルなままでもいなじゃない、とのことだった。納得した。