Cloudflareプロキシの背後にMatrixサーバーをセットアップする方法

MatrixサーバーはCloudflareの背後に配置できますが、その設定はクライアントや他のホームサーバーがどのようにサーバーを検出するかによって異なります。Cloudflareの標準HTTPプロキシはポート443でHTTPSをサポートしていますが、Synapseフェデレーションは通常ポート8448をデフォルトとして使用します。このポートはCloudflareの標準プロキシポートリストには含まれていません。確実な設定としては、リバースプロキシ経由でSynapseを443番ポートに公開し、クライアントとフェデレーションのトラフィックをそのホスト名に誘導するMatrixのウェルノウンレコードを公開する方法があります。あるいは、フェデレーションを8448番ポートに維持し、そのDNSレコードをDNS専用にすることもできます。

このガイドでは、公式のMatrixホームサーバー実装であるSynapseと、サンプルとして示されているMatrix ID@alice:example.comおよびクライアントエンドポイントを使用しますmatrix.example.com。これらの名前とアドレスは、ご自身のものに置き換えてください。この手順は、SynapseとHTTPSリバースプロキシが既にインストールされていることを前提としています。すべてのホームサーバー実装にそのまま適用できるわけではありません。2026年10月6日時点のCloudflareおよびElement Synapseの最新ドキュメントに基づいて検証済みです。

適切なネットワークレイアウトを選択してください

Cloudflareのorange-cloudプロキシは、HTTP/HTTPSリバースプロキシです。クライアントとオリジンサーバーの間に入り、プロキシされたWebリクエストを処理します。すべてのTCPポートをプロキシするわけではありません。標準のHTTPSポートには443と8443が含まれますが、Synapseで一般的に使用されるフェデレーションポート8448は含まれません。Cloudflareがサポートするネットワークポートとプロキシの制限事項については、こちらをご覧ください。

最初のレイアウトは以下で使用されます。プロキシされたDNSレコードは、それ自体ではMatrixの検出、リバースプロキシ、TLS、またはファイアウォールポリシーを構成しません。

1. DNSを設定する前に、Matrixサーバー名を決定します。

Matrixサーバー名は、ユーザーIDのコロン以降の部分です。この例では なのでexample.com、ユーザーのIDは のようになります@alice:example.com。技術的なクライアントホスト名は ですmatrix.example.com。この分離により、トラフィックが別のホスト名に委任されても、ユーザーIDで使用されるドメインは安定したままになります。Synapseが既に初期化されている場合は、安易に変更しないでくださいserver_name。これはユーザーとルームのIDの一部であり、変更するとプロキシの調整ではなく移行になります。

サーバー名ドメインから2つの小さなJSONディスカバリドキュメントを配信する計画：

• https://example.com/.well-known/matrix/client互換性のあるクライアントに、それを使用するように指示しますhttps://matrix.example.com。
• https://example.com/.well-known/matrix/server他のホームサーバーにフェデレーションにアクセスするように指示しますmatrix.example.com:443。

クライアント文書にはAccess-Control-Allow-Origin: *レスポンスヘッダーが必要です。Synapse委任ガイドには、これらのレコードの例と想定される構造が記載されています。Synapseフェデレーション委任。

2. CloudflareのDNSレコードを作成する

Cloudflare DNS で、サーバーのパブリック IPv4 アドレスを指すAレコードを作成します。オリジンが IPv6 接続を正常に機能しており、ファイアウォールが IPv6 用に構成されている場合にのみ、レコードを追加します。Web ホスト名のプロキシ ステータスを「プロキシ済み」（オレンジ色の雲）に設定します。ルート ドメインもこのサーバーを指しており、よく知られているファイルを提供する場合は、その Web レコードもプロキシします。matrixAAAA

メールレコードを含む無関係なレコードは、適切な DNS のみの設定で保持します。MX レコードと TXT レコードはプロキシされません。Cloudflare は、プロキシされた A、AAAA、または CNAME レコードは HTTP/HTTPS リクエストを Cloudflare 経由でルーティングする一方、DNS のみでは発信元アドレスが直接返されると説明しています: Cloudflare プロキシ ステータスの動作。

CloudflareからオリジンサーバーへのHTTPS受信を許可してください。より強力な保護のためには、オリジンファイアウォールをCloudflareが公開しているIPアドレス範囲に制限し、その範囲を常に最新の状態に保ってください。ゾーンがアクティブになる前にサーバーのIPアドレスが公開されていた場合、DNSプロキシを使用しても古いアドレスは無効になりません。アクティブ化後にオリジンIPアドレスを変更することを検討してください。オレンジ色の雲マークだけでオリジンサーバーへの直接アクセスが防止されるとは考えないでください。

3. Cloudflareとオリジンサーバー間でHTTPSを設定する

Cloudflare の SSL/TLS 設定では、オリジンがホスト名に対して有効な証明書（公開されている信頼できる証明書や Cloudflare Origin CA 証明書など）を提示する場合に、 [完全（厳密）]を使用してください。[完全（厳密）] では、Cloudflare とオリジン間の接続が暗号化され、オリジン証明書が検証されます。[柔軟] モードでは、同じエンドツーエンドの TLS パスは提供されません。Cloudflareの [完全（厳密）] に関するドキュメントを参照してください。

証明書と秘密鍵は、必ずしもSynapseではなく、リバースプロキシにインストールしてください。リバースプロキシはパブリックポート443でリッスンし、Matrixからのリクエストを内部的にSynapseのHTTPリスナー（通常はポート8008）に転送する必要があります。リバースプロキシを唯一のエントリポイントとする場合は、Synapseリスナーを公開しないでください。

4. Synapseに、信頼できるリバースプロキシの背後にあることを伝える

の該当する HTTP リスナーでhomeserver.yaml、転送ヘッダーの処理を有効にします。コンテナ化されていないサーバーの簡略化された例は次のとおりです。

listeners:
  - port: 8008
    type: http
    tls: false
    x_forwarded: true
    bind_addresses: ['127.0.0.1']
    resources:
      - names: [client, federation]
        compress: false

これらの設定は、構成全体を置き換えるのではなく、既存のリスナーに統合してください。Synapse の公式ドキュメントでx_forwarded: trueは、リバースプロキシの背後での使用を推奨しており、プロキシが同じホストで実行されている場合は localhost にバインドすることを提案しています。コンテナ展開の場合、Synapse をコンテナのループバックにバインドすると、ホストプロキシがコンテナに到達できなくなる可能性があります。代わりに、コンテナまたはサービスのネットワーク アドレスを使用し、そのパスをファイアウォールで保護してください。リスナー設定を変更する前に、最新のSynapse リバースプロキシ ガイドを確認してください。

転送されたヘッダーは、Synapse が制御プロキシからのトラフィックを受け入れる場合にのみ信頼できます。Cloudflare が唯一のインターネット接続ルートである場合は、オリジンへの直接のパブリックアクセスを防止し、プロキシを設定して正しいクライアント アドレスを渡すようにしてください。$remote_addrそうしないと、Cloudflare が Nginx に接続しているため、Nginx のアドレスは Cloudflare のアドレスになります。Nginx の real-IP モジュールを設定して、Cloudflare が公開しているソース範囲のみを信頼するようにしてから使用してくださいCF-Connecting-IP。任意のインターネット クライアントからのヘッダーは決して信頼しないでください。Synapse 管理 API は、公開する特別な理由がない限り非公開にしてください。

5. マトリックスパスを書き換えずにルーティングする

リバースプロキシを設定して、 と の両方/_matrixを/_synapse/clientSynapse に送信するようにしてください。リクエスト URI は正確に保持してください。プロキシがエンコードされたパス セグメントをデコードまたは正規化すると、Synapse フェデレーション リクエストの署名が失敗する可能性があります。

以下は、Nginx の簡潔な例ですmatrix.example.com。この例では、TLS 証明書ディレクティブがこのサーバーブロック用に既に設定されており、リバースプロキシと Synapse が同じホスト上で実行されていることを前提としています。

server {
    listen 443 ssl;
    server_name matrix.example.com;

    location ~ ^(/_matrix|/_synapse/client) {
        proxy_pass http://127.0.0.1:8008;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Host $host;
        proxy_http_version 1.1;
        client_max_body_size 50M;
    }
}

この正規表現の場所にはURIサフィックスを追加しないでくださいproxy_pass。Synapseのプロキシドキュメントでは、URIの正規化がフェデレーション署名エラーの原因となることが指摘されています。また、client_max_body_sizeSynapseのアップロード制限と、ゾーンに適用されるCloudflareプランの制限に合わせて調整してください。50M上記の値はあくまで例であり、普遍的な推奨事項ではありません。

CloudflareはプランでWebSocketをサポートしており、Matrixクライアントは長時間接続を使用できます。プロキシがアップグレードを許可していること、およびWAFやレート制限ルールが正当なMatrixリクエストを拒否していないことを確認してください。CloudflareのWebSocketに関するドキュメントには、アップグレードされた接続の処理方法が記載されています。

6. よく知られている回答を公開する

以下の2つのレスポンスをexample.comHTTPS経由で送信してください。これらのレスポンスは、Webサーバー、静的ホスト、または別の仮想ホストから返すことができます。クライアントとフェデレーションのドキュメントは区別してください。

GET /.well-known/matrix/client
HTTP/1.1 200 OK
Content-Type: application/json
Access-Control-Allow-Origin: *

{"m.homeserver":{"base_url":"https://matrix.example.com"}}

GET /.well-known/matrix/server
HTTP/1.1 200 OK
Content-Type: application/json

{"m.server":"matrix.example.com:443"}

Matrixの検出要件とクライアントの動作を確認せずに、無関係なホストへのリダイレクトを代替手段として使用しないでください。サーバー名ホストが有効なHTTPS証明書で保護されていること、および変更中にCloudflareが古い検出応答をキャッシュしないことを確認してください。

7. APIトラフィックを動的に保ち、アップロードを制限内に収める

認証済みの Matrix API レスポンスはキャッシュしないでください。特定の公開レスポンスを異なる方法で処理する理由が十分に検証されている場合を除き、/_matrix/*およびを含む Matrix API パスのキャッシュをバイパスする Cloudflare キャッシュ ルール/_synapse/client/*を追加してください。フェデレーション エンドポイントに異議を唱えたりブロックしたりする広範な WAF またはボット ルールは避けてください。フェデレーション リクエストは、多くの独立したホーム サーバーから送信されます。セキュリティ ルールが必要な場合は、一般的に適用する前に、クライアント ログイン、同期、メディア アップロード、およびフェデレーションに対してテストしてください。

アップロードには、クライアント、Cloudflare のプランまたはゾーンのアップロード設定、リバースプロキシのボディサイズ制限、および Synapse の制限など、複数の独立した上限があります。413max_upload_sizeエラーは、これらの制限のいずれかがリクエストを拒否したことを意味します。Cloudflare はプランに応じたアップロード制限を公開しており、これらの設定はドキュメントに記載されている制約内で調整できると記載しています。Cloudflareの 413 トラブルシューティング ページを参照してください。必要な制限のみを引き上げ、さらに引き上げる前に、設定された上限よりも小さいファイルでテストしてください。

8. クライアントのアクセス、検出、およびフェデレーションを確認する

サーバーのネットワーク外のマシンからこれらのチェックを実行してください。例のホスト名を置き換えてください。

curl -i https://example.com/.well-known/matrix/client
curl -i https://example.com/.well-known/matrix/server
curl -i https://matrix.example.com/_matrix/client/versions
curl -i https://matrix.example.com/health

最初の 2 つのリクエストは、HTTP 200、JSON コンテンツ、および期待される値を返す必要があります。クライアント ドキュメントには CORS ヘッダーを含める必要があります。クライアント バージョン エンドポイントは、Cloudflare を介して Synapse から JSON を返す必要があります。Synapse のヘルス エンドポイントは、設定済みのリスナー経由でアクセスされると HTTP 200 を返しますが、ログインやフェデレーションの確認の代わりにはなりません。

次に、末尾が の ID を使用して Matrix クライアントでサインインし:example.com、別の場所でホストされているルームに参加して、メッセージとメンバーシップの更新が同期されることを確認します。Matrix フェデレーション テスターまたは別のホームサーバーを使用して、サーバーの検出とフェデレーションを検証します。 へのリクエストが成功した/_matrix/client/versionsとしても、クライアント側のルートが機能していることは証明されるだけで、フェデレーションの検出、署名、または送信フェデレーションが正しいことは証明されません。

成功とはどのようなものか、そしていつデザインを変更すべきか

• クライアントはCloudflare経由で接続します。DNSはCloudflareのアドレスに解決され、HTTPSは指定された証明書を使用し、MatrixクライアントAPIは応答を返します。
• 検出結果は正しい。既知のURLはいずれも正しいJSONを返し、クライアントドキュメントはクロスオリジンチェックに合格している。
• フェデレーションが機能する場合：リモートサーバーがアドバタイズされたエンドポイントを検出し、ルームの状態を交換できます。443番ポートへの委任が失敗し、8448番ポートへの直接接続が機能する場合は、既知のレコード、プロキシパスルーティング、およびWAFルールを確認してください。
• アップロードは想定サイズで正常に動作します。代表的なサイズのファイルをアップロードしてテストしてください。小さなファイルはアップロードに成功するのに、大きなファイルで413エラーが発生する場合は、Synapseだけを変更するのではなく、4つのサイズ制限すべてを比較してください。
• オリジンは代替のパブリックパスではありません。設計どおり、オリジンへの直接リクエストはブロックまたは制限されるはずです。それでもMatrixサービスに到達してしまう場合は、ファイアウォールと信頼済み​​プロキシの設定を修正してください。

要件や実装上、443番ポートでフェデレーションをルーティングできない場合は、8448番ポートでDNSのみのフェデレーションを使用してください。ただし、この場合、発信元アドレスが公開され、そのホスト名に対するCloudflareのHTTPプロキシ保護が無効になることに注意してください。Spectrumは、製品の可用性とプランの制約に応じて、標準以外のポートの別のオプションです。Cloudflareプロキシを使用すると、2番目のTLS接続が発信元アドレスに接続される前に、CloudflareでTLSが終了します。Matrixエンドツーエンド暗号化は暗号化されたメッセージコンテンツを保護しますが、接続メタデータやエンドツーエンド暗号化されていないコンテンツは、HTTPリクエストを処理するサービスから隠されません。プライバシー、フェデレーション、可用性の要件に基づいてトポロジを選択し、DNS、証明書、Synapse、またはCloudflareルールを変更した後に再テストしてください。