Skip to content

非公式本サイトは非公式の日本語ドキュメントであり、Cloudflare 公式サイトではありません。最新情報はdevelopers.cloudflare.comをご確認ください。

設定ファイル

最終更新 Markdown で表示Agent セットアップ

ローカル管理トンネルは、マシン上の cloudflared インスタンスとして動きます。cloudflared のプロパティは、コマンドラインパラメーター を変更するか、トンネルの 設定ファイル を編集して設定できます。

単一のサービスを cloudflared 経由で接続する場合、CLI で素早く設定できます。複数のサービスを接続し、オリジンごとにプロパティや例外を設定する必要がある場合は、トンネルの設定ファイルが便利です。設定ファイルでは、cloudflared インスタンスのトップレベルプロパティと、オリジン固有のプロパティ を定義できます。設定オプションの一覧は、ターミナルで cloudflared tunnel help を実行してください。

設定ファイルがない場合、cloudflared は送信トラフィックをポート 8080 経由でプロキシします。

公開アプリケーションのファイル構造

ローカルサービスをインターネットに公開する場合は、サービスごとに公開ホスト名を割り当てられます。

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

ingress ルールを含む設定ファイルは、必ずファイル末尾にキャッチオールルールを置く必要があります。この例では、どのホスト名にも一致しないリクエストに対して、cloudflared は 404 ステータスコードで応答します。

トラフィックの照合方法

cloudflared は受信リクエストを受け取ると、上から下へ各 ingress ルールを評価し、一致するルールを探します。ルールは、受信リクエストのホスト名、パス、またはその両方に一致できます。ルールにホスト名を指定しない場合は、すべてのホスト名に一致します。ルールにパスを指定しない場合は、すべてのパスに一致します。

最後の ingress ルールは、すべてのトラフィックに一致するキャッチオールルールである必要があります。

複数のルールを定義した設定ファイルの例です。

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

ingress:
  # Rules map traffic from a hostname to a local service:
  - hostname: example.com
    service: https://localhost:8000
  # Rules can match the request's path to a regular expression:
  - hostname: static.example.com
    path: \.(jpg|png|css|js)$
    service: https://localhost:8001
  # Rules can match the request's hostname to a wildcard character:
  - hostname: "*.example.com"
    service: https://localhost:8002
  # An example of a catch-all rule:
  - service: https://localhost:8003

ワイルドカード

ワイルドカードを使うと、複数のサブドメインへのトラフィックに一致できます。たとえば hostname キーを *.example.com にすると、alpha.example.com と beta.example.com の両方のトラフィックがオリジンへ送られます。cloudflared は、test.*.example.com のようにホスト名の途中にあるワイルドカードをサポートしません。

path キーには正規表現も指定できます。たとえば hostname が static.example.com、path が \.(jpg|png|css|js)$ の場合、一致する URL には https://static.example.com/data.js や http://static.example.com/images/photo.jpg などがあります。Cloudflare はパスの正規表現を Go の syntax パッケージ ↗ で解析します。

サービス

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:
  # Example of a request over TCP:
  - hostname: example.com
    service: tcp://localhost:8000
  # Example of an HTTP request over a Unix socket:
  - hostname: staging.example.com
    service: unix:/home/production/echo.sock
  # Example of a request mapping to the Hello World test server:
  - hostname: test.example.com
    service: hello_world
  # Example of a rule responding to traffic with an HTTP status:
  - service: http_status:404

オリジンの設定

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

次の例では、トップレベルの設定 connectTimeout: 30s が、その cloudflared インスタンス内の全サービスに 30 秒の接続タイムアウトを設定します。service: localhost:8002 の ingress ルールは、そのサービスの connectTimeout を 10s にして、トップレベル設定の例外を作ります。ほかのサービスには、引き続き 30 秒の接続タイムアウトが適用されます。

tunnel: 6ff42ae2-765d-4adf-8112-31c55c1551ef
credentials-file: /root/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json
originRequest: # Top-level configuration
  connectTimeout: 30s

ingress:
  # The localhost:8000 service inherits all root-level configuration.
  # In other words, it will use a connectTimeout of 30 seconds.
  - hostname: example.com
    service: localhost:8000
  - hostname: example2.com
    service: localhost:8001
  # The localhost:8002 service overrides some root-level config.
  - service: localhost:8002
    originRequest:
      connectTimeout: 10s
      disableChunkedEncoding: true
  # Some built-in services such as `http_status` do not use any configuration.
  # The service below will simply respond with HTTP 404.
  - service: http_status:404

ingress ルールを検証する

設定ファイルの ingress ルールを検証するには、次を実行します。

cloudflared tunnel ingress validate

設定ファイルに指定した ingress ルールの集合が有効であることを確認します。

ingress ルールをテストする

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 レプリカ を使うことを推奨します。

  1. 元の設定ファイルで cloudflared インスタンスを動かします。
  2. 更新した設定ファイルで cloudflared レプリカを起動します。
  3. レプリカが完全に起動し、使える状態になるまで待ちます。
  4. 最初の cloudflared インスタンスを停止します。

これで、cloudflared は更新後の設定ファイルで動きます。

役に立ちましたか？