設定ファイル

トンネルの設定ファイルを使用すると、cloudflaredのインスタンスがどのように動作するかを詳細に制御できます。設定ファイルでは、cloudflaredインスタンスのトップレベルプロパティを指定したり、オリジン固有のプロパティを設定したりできます。設定オプションの完全なリストを表示するには、ターミナルでcloudflared tunnel helpと入力してください。

設定ファイルがない場合、cloudflaredはポート8080を介してアウトバウンドトラフィックをプロキシします。

プライベートネットワークのファイル構造

WARPを実行しているエンドユーザーにプライベートネットワークを公開する場合、warp-routingキーを追加し、trueに設定する必要があります：

tunnel: <Tunnel-UUID>
credentials-file: /path/<Tunnel-UUID>.json
warp-routing:
  enabled: true

パブリックホスト名のファイル構造

ローカルサービスをインターネットに公開する場合、各サービスにパブリックホスト名を割り当てることができます：

tunnel: 6ff42ae2-765d-4adf-8112-31c55c1551ef
credentials-file: /root/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json

ingress:
  - hostname: gitlab.widgetcorp.tech
    service: http://localhost:80
  - hostname: gitlab-ssh.widgetcorp.tech
    service: ssh://localhost:22
  - service: http_status:404

インバウンドルールを含む設定ファイルには、常にファイルを締めくくるキャッチオールルールを含める必要があります。この例では、cloudflaredはリクエストが以前のホスト名のいずれにも一致しない場合、404ステータスコードで応答します。

トラフィックのマッチング方法

cloudflaredが受信リクエストを受け取ると、リクエストに一致するルールを見つけるために、上から下へ各インバウンドルールを評価します。ルールは、受信リクエストのホスト名またはパス、またはその両方に一致することができます。

ルールがホスト名を指定しない場合、すべてのホスト名が一致します。ルールがパスを指定しない場合、すべてのパスが一致します。

最後のインバウンドルールは、すべてのトラフィックに一致するキャッチオールルールでなければなりません。

以下は、いくつかのルールを指定した設定ファイルの例です：

tunnel: 6ff42ae2-765d-4adf-8112-31c55c1551ef
credentials-file: /root/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json

ingress:
  # ルールはホスト名からローカルサービスへのトラフィックをマッピングします：
  - hostname: example.com
    service: https://localhost:8000
  # ルールはリクエストのパスを正規表現にマッチさせることができます：
  - hostname: static.example.com
    path: \.(jpg|png|css|js)$
    service: https://localhost:8001
  # ルールはリクエストのホスト名をワイルドカード文字にマッチさせることができます：
  - hostname: "*.example.com"
    service: https://localhost:8002
  # キャッチオールルールの例：
  - service: https://localhost:8003

サポートされているプロトコル

HTTPに加えて、cloudflaredはSSH、RDP、任意のTCPサービス、Unixソケットなどのプロトコルをサポートしています。また、組み込みのHello Worldテストサーバーにトラフィックをルーティングしたり、HTTPステータスでトラフィックに応答したりすることもできます。

tunnel: 6ff42ae2-765d-4adf-8112-31c55c1551ef
credentials-file: /root/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json

ingress:
  # TCP経由のリクエストの例：
  - hostname: example.com
    service: tcp://localhost:8000
  # Unixソケット経由のHTTPリクエストの例：
  - hostname: staging.example.com
    service: unix:/home/production/echo.sock
  # Hello Worldテストサーバーにマッピングされるリクエストの例：
  - hostname: test.example.com
    service: hello_world
  # HTTPステータスでトラフィックに応答するルールの例：
  - service: http_status:404

サービス	説明	例 `service` 値
HTTP/S	受信HTTPリクエストはローカルサービスに直接プロキシされます。	`https://localhost:8000`
Unixソケット経由のHTTP	HTTPと同様ですが、Unixソケットを使用します。	`unix:/home/production/echo.sock`
Unixソケット経由のHTTPS	HTTPSと同様ですが、Unixソケットを使用します。	`unix+tls:/home/production/echo.sock`
TCP	TCP接続はローカルサービスにプロキシされます。	`tcp://localhost:2222`
SSH	SSH接続はローカルサービスにプロキシされます。詳細はこちら。	`ssh://localhost:22`
RDP	RDP接続はローカルサービスにプロキシされます。詳細はこちら。	`rdp://localhost:3389`
kubectlバスティオンモード	`cloudflared`はジャンプホストとして機能し、任意のローカルアドレスへのアクセスを許可します。	`bastion`
Hello World	Cloudflareトンネルのセットアップを検証するためのテストサーバー。	`hello_world`
HTTPステータス	すべてのリクエストに指定されたHTTPステータスで応答します。	`http_status:404`

オリジン設定

1つのcloudflaredインスタンス内で複数のオリジンにトラフィックをプロキシする必要がある場合、インバウンドルールの一部として設定オプションを指定することで、cloudflaredが各サービスにリクエストを送信する方法を定義できます。

以下の例では、トップレベルの設定connectTimeout: 30sが、そのcloudflaredインスタンス内のすべてのサービスに対して30秒の接続タイムアウトを設定します。service: localhost:8002のインバウンドルールは、そのサービスのconnectTimeoutを10sに設定することで、トップレベルの設定に対する例外を構成します。30秒の接続タイムアウトは、他のすべてのサービスにも適用されます。

tunnel: 6ff42ae2-765d-4adf-8112-31c55c1551ef
credentials-file: /root/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json
originRequest: # トップレベルの設定
  connectTimeout: 30s

ingress:
  # localhost:8000サービスはすべてのルートレベルの設定を継承します。
  # 言い換えれば、30秒のconnectTimeoutを使用します。
  - hostname: example.com
    service: localhost:8000
  - hostname: example2.com
    service: localhost:8001
  # localhost:8002サービスは一部のルートレベルの設定をオーバーライドします。
  - service: localhost:8002
    originRequest:
      connectTimeout: 10s
      disableChunkedEncoding: true
  # `http_status`のような一部の組み込みサービスは設定を使用しません。
  # 以下のサービスは単にHTTP 404で応答します。
  - service: http_status:404

インバウンドルールの検証

設定ファイルのインバウンドルールを検証するには、次のコマンドを実行します：

cloudflared tunnel ingress validate

これにより、設定ファイルに指定されたインバウンドルールのセットが有効であることが確認されます。

インバウンドルールのテスト

cloudflaredが正しいトラフィックを正しいローカルサービスにプロキシするかどうかを確認するには、cloudflared tunnel ingress ruleを使用します。これにより、URLが最初から最後まで各ルールに対してチェックされ、一致する最初のルールが表示されます。たとえば：

cloudflared tunnel ingress rule https://foo.example.com

Using rules from /usr/local/etc/cloudflared/config.yml
Matched rule #3
  hostname: *.example.com
  service: https://localhost:8000

設定ファイルの更新

特定のトンネルの設定ファイルに変更を加える場合、ダウンタイムを最小限に抑えるためにcloudflaredレプリカに依存することをお勧めします。

元の設定ファイルのバージョンでcloudflaredインスタンスを実行します。
更新された設定ファイルのバージョンでcloudflaredレプリカを起動します。
レプリカが完全に実行可能であることを確認します。
最初のcloudflaredインスタンスを停止します。

これで、cloudflaredは更新された設定ファイルのバージョンで実行されるようになります。

Cloudflare Dashboard Discord Community Learning Center Support Portal

Cookie Settings