Cloudflare エージェントの設定

Aivory を Cloudflare にバックアップすると、次のような 3 つの方法が得られます。ソースステーションIPを隠す(訪問者は Cloudflare エッジノードのアドレスしか見ることができません。無料で自動更新可能なエッジ証明書(ブラウザからCloudflareのこの段階のHTTPSはあなたを心配する必要はありません)、およびCloudflareのDDoS緩和と基本 WAF付属の利点は、近接アクセスおよび静的リソースのエッジキャッシュに関する全世界のAnycastです。

このページでは、完全な2つのルートを提供しています:

プロジェクトA:オレンジ雲代理. ソースステーションには公共の IP があり、DNS レコードが Cloudflare エージェント (オレンジクラウド) を開いており、トラフィックパスは「訪問者 → Cloudflare → ソースステーション Nginx → app」です。
プログラムB:Cloudflareトンネルソースステーションには公共ネットワークのIPがない、または入力ポートを開くことを望んでいないcloudflaredコンテナは Cloudflare への出力トンネルを積極的に構築します。

両方のルートは同じ事実に基づいています:Aivoryのappコンテナ単容器同源サービング SPAおよび/apiどのドメイン名を使うか、どのドメイン名を使うか必要ないCloudflare への変更ALLOWED_ORIGINSまたは、ドメイン名の構成(この変数は前後分離デプロイ時にのみ有意義である)。

前提条件:ドメイン名へのアクセス Cloudflare

Cloudflare アカウントを登録し、パネルをクリックAdd a domainドメイン名を入力する(例えば、example.comフリーパッケージを選択します。
Cloudflare は既存の DNS レコードをスキャンし、2 つの NS サーバーアドレスを提供し、Domain Name Server を両方のアドレスに変更します。
状態が変わるのを待つ。Active(通常は数分から数時間)、その後、DNS とエージェントは Cloudflare パネルで管理されます。

Aivory 側の基本的なデプロイが完了したことを確認します。Docker Compose 生産展開計画Aは既に実施され、計画Aも実施されている。リバースプロキシとHTTPSソースステーションに Nginx をインストールします。

プロジェクトA:オレンジ雲代理

ステップ 1: DNS レコードがオレンジクラウドを開く

Cloudflare パネルでDNS → Recordsソースステーションのレコードを追加(または変更)し、Proxy status設立為Proxied(オレンジ雲):

Type	Name	Content	Proxy status
A	`chat`	ソースステーション IPv4 アドレス	Proxied(オレンジ雲)
AAAA	`chat`	ソースステーションの IPv6 アドレス(存在する場合)	Proxied(オレンジ雲)

オレンジ雲が開いた後、dig chat.example.comCloudflare のエッジ IP を解析し、ソースステーションの実際のアドレスはもはや外部に暴露されていません。

より徹底的に源泉を隠す

オレンジクラウドでは、DNS がソースステーションの IP を漏らさないようにするだけです。ソースステーションのファイアウォールレベルが Cloudflare からのバックソーストラフィックのみを受け取ることを望む場合は、ファイアウォール(ufw / Cloud セキュリティグループ)で Cloudflare が公式に発表したバックソースネットワークセクション (https://www.cloudflare.com/ips/) のみ 443 ポートにアクセスできます。このステップは機能に影響を与えず、オプションで強化できます。

ステップ 2: SSL/TLS 暗号化モードを選択する

在 SSL/TLS → Overview暗号化モードを選択します。この 3 つのモードの違いは、「Cloudflare からソースステーション」の段落にあります。

モデル	ブラウザ → Cloudflare	Cloudflare → ソースステーション	源泉要請	勧めるか
Flexible	HTTPS	HTTPの説明	ソースステーションは単に80を監視するだけで、証明書は必要ありません	内部ネットワークのみ/信頼性の高いリンク
Full	HTTPS	HTTPSですが、非学校証明書	任意の証明書(署名を含む)	移行用
Full (strict)	HTTPS	HTTPS,学校証明書の有効性	信頼される真の証明書	推奨

**推奨フル (strict)**源駅按リバースプロキシとHTTPSLet's Encrypt 証明書を搭載して要求事項を満たします。 certbot を実行したくない場合は、SSL/TLS → Origin ServerCloudflare Origin CA 証明書(最大 15 年間、Cloudflare バックソースのみで信頼される)をソースステーション Nginx にインストールし、Full (strict) を満たします。

ソースステーションはHTTPのみでFlexibleの利点と欠点:

利点:Aivory は生産環境の HTTP デプロイをサポートします(アプリケーションのリクエスト署名アルゴリズムは純粋に JS リバウンドであり、ブラウザの安全なコンテキストの暗号化 API に依存しません)。https://ページのアドレスはセキュアで、その逆です。純粋な HTTP デプロイの様々なブラウザ制限を回避ソースステーションは、証明書を設定しないで、ゼロ証明書運用コストの最速の方法です。
マイナス:Cloudflare to source station このセクションは明確で、どの中間ネットワークでもトラフィックコンテンツ(ログイン証明書や会話コンテンツを含む)が表示されます。このリンクは信頼性がある場合にのみ使用することをお勧めします(インスタルネット、クラウドプロバイダーのプライベートネットワークなど)。

柔軟なモードで最も一般的な回転:死のサイクルへのリダイレクト

リバースプロキシとHTTPS例 Nginx 設定では、80 ポートのリクエストを 301 から HTTPS に変換します。 Flexible モードでは、Cloudflare は HTTP を常に使用し、ソースステーションは常に 301 回使用します。https://ブラウザは無制限のリダイレクトに陥ります。Flexible では、ソースステーション 80 ポートは HTTPS ジャンプなしに直接ビジネスをサーバーする必要があります。

柔軟なモードのソースステーション Nginx (純粋な HTTP で、SSE とリアル IP 処理を保持する):

server {
    listen 80;
    listen [::]:80;
    server_name chat.example.com;

    # 普通上传默认上限 50MB(MAX_UPLOAD_BYTES),留出余量
    client_max_body_size 100m;

    location / {
        proxy_pass http://127.0.0.1:8787;

        # SSE 流式输出
        proxy_buffering off;
        proxy_read_timeout 3600s;
        proxy_http_version 1.1;
        proxy_set_header Connection "";

        # 真实客户端 IP(配合下一步的 real_ip 配置)
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Flexible + OAuth の組み合わせ

Flexible モードのソースステーションリンクは HTTP で、OAuth ログインを設定している場合は、OAUTH_CALLBACK_BASE_URL明らかに外部にhttps://chat.example.comアドレスを返すのを避ける。http://OAuth プロバイダー側で https リコムアドレスを同期して登録します。FAQ。

ステップ 3: ソースステーション Nginx が実際の訪問者 IP を復元する

このステップ無視できないAivory はクライアント IP メンテナンス制限ストリームをカウントし、ルールは、直接接続が内部ネットワークまたは回路アドレスである場合にのみ信頼されることです。X-Forwarded-For / X-Real-IP(右側の非内網の項目を参照) 直線公衆網対端時にはこれらの頭を無視する。

オレンジクラウドを起動すると、ソースステーション Nginx が見る TCP 対端は Cloudflare エッジノードです。復元が行われない場合、Nginx がアプリに転送する「実際の IP」は Cloudflare ノードの IP です: 世界中の訪問者は数少ない Cloudflare ノードのアドレスに折りたたてられ、トラフィックの制限数を共有し、一人で起動する制限ストリームが多数のユーザーに接続されます。

Cloudflare は、訪問者のリアルな IP を配置しますCF-Connecting-IPリクエストヘッドで Nginx で real_ip モジュールを復元:新しく作成/etc/nginx/conf.d/cloudflare-realip.conf内容は以下の通り。

# /etc/nginx/conf.d/cloudflare-realip.conf
# 信任的 Cloudflare 回源网段,官方列表:https://www.cloudflare.com/ips/
# IPv4
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;

# IPv6
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2a06:98c0::/29;
set_real_ip_from 2c0f:f248::/32;

# 从 Cloudflare 注入的头里取访客真实 IP
real_ip_header CF-Connecting-IP;

sudo nginx -t
sudo systemctl reload nginx

主流の発行版nginx.confデフォルト含むinclude /etc/nginx/conf.d/*.conf;(httpブロック内)、上記のファイルは自動的に有効になりますが、ディストリビューションがない場合は、このコンテンツを任意の httpブロックレベルの構成に組み込むことができます。

働く原則は、完全な信頼チェーンです。

real_ip モジュールが表示されます。set_real_ip_fromホワイトリストで、CF-Connecting-IP値 * 表記$remote_addr*この時点で$remote_addr訪問者の本当のIP。
元のサーバーのproxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;変更する必要がなく、復元後の実際のIPを追加します。X-Forwarded-ForApp に転送します。
次に、アプローチの端末は(127.0.0.1:8787)、「内ネット/回路」の条件を満たし、その頭を信頼し、右側の非内ネットエントリを取ると、訪問者の本当のIPが得られる。

検証:再ロード後サイトへのアクセス、tail -f /var/log/nginx/access.logソース IP は、Cloudflare セグメントのアドレスではなく、あなた自身のパブリック IP でなければなりません。

ネットリストは変わる?

Cloudflare のバックソースネットワークセクションは長年にわたって安定していますが、公式のパールリストを時々チェックすることをお勧めします。 1 つのコマンドで設定主体を再生成できます:

{ curl -s https://www.cloudflare.com/ips-v4; echo; curl -s https://www.cloudflare.com/ips-v6; } \
  | sed '/^$/d; s/^/set_real_ip_from /; s/$/;/'

SSE 長い接続:開箱で使えますが、API をキャッシュしないでください

Aivory の AI 応答は WebSocket なしで SSE (Server-Sent Events) ストリーミングで送信されます。Cloudflare エージェントの SSE への送信は、以下の 2 つの理由でオープンボックスです。

余暇時間Cloudflare エージェント接続のフリータイムは約 100 秒で、Aivory サーバは 15 秒ごとに ping ハートを発信し、接続は決してフリータイムと判断されず、長い回答とディプリサーチタスクは中断されません。追加配置は必要ありません。。
バッファCloudflare はキャッシュにアクセスしない応答に全体的なバックアップを行っておらず、API 応答がキャッシュされない限り、トークンはリアルタイムでブラウザに到達します。

したがって、Cloudflare 側で保証する唯一のことは、以下のことです。/api/*キャッシュにアクセスしない**(次のセクションのキャッシュルール処理) ソースステーションの Nginx 側proxy_buffering off読書時間の延長は、見ておかなければなりません。リバースプロキシとHTTPS。

Cache Rules: API を回避し、静的リソースをキャッシュする

Cloudflare デフォルトはキャッシュなしtext/htmlAPI のようなダイナミックな対応では、理論上はルールに合わないことも正常に機能しますが、明示的な声明は「Cache Everything」などのグローバルなルールを間違えるときに API を間違えられるようにします。Caching → Cache Rules2つのルールを構築する:

ルール	匹敵条件	動き	説明
火が通り過ぎる	URI Path starts with `/api/`	Bypass cache	SSE がすべてのインターフェイスとキャッシュされないようにする
静的資源	URI Path starts with `/assets/`	Eligible for cache, Edge TTL 設定(たとえば 1 か月)	プロダクトファイル名を構築し、コンテンツの指紋を持ち、ファイル名が変更され、長いキャッシュは絶対に安全です。

ルールの順序:APIが前面に置かれている(Cache Rulesが順序で一致する)。

パネルスイッチ:開くべきと閉じるべき

スイッチ	位置	提案	理由
Rocket Loader	Speed → Optimization	閉鎖	スクリプトのロード順序をリセットし、SPAに白い画面や機能異常を引き起こす
Always Use HTTPS	SSL/TLS → Edge Certificates	オープン	すべての`http://`訪問先 301 へ`https://`
Auto Minify	无	取り扱い不要	この機能は Cloudflare でダウンロードされているので、探す必要はありません。
Brotli 圧縮	Speed	黙認(開)	デフォルトが有効
HTTP/2 / HTTP/3	Network	黙認(開)	デフォルトが有効
WebSockets	Network	無関係	Aivory ストリームは WebSocket ではなく SSE で、このスイッチはオフとオフに影響を与えません

リクエストの上限と「バックアップインポート」を回避

Cloudflare では、パッケージごとに個々のリクエストのサイズを制限します。

パック	要求体上限
Free / Pro	100MB
Business	200MB
Enterprise	500MB

Aivory の 2 つの大リクエスト対象:

シーン	サービス上限の設定	オレンジ雲の影響
一般文書/資料のアップロード(`MAX_UPLOAD_BYTES`)	50MB	影響を受けず、Freeパッケージがカバーできます
管理者登録(`MAX_BACKUP_BYTES`)	20GiB	Cloudflare によって拒否されるどのパッケージも足りない。

管理者実施バックアップ入力アーカイブは最大 20 GiB で、Cloudflare エージェントを回避して選択する必要があります。

**インターネット接続(推奨)**サーバー本体または内部ネットワークへの直接アクセスhttp://127.0.0.1:8787管理コンソールの実行インポートは、Cloudflare およびソースステーション Nginx のサイズ制限が全くありません。
灰雲子域別のDNSレコードを作成します。direct.chat.example.comプロキシステータス設定DNS only(グレー・クラウド)、ソース・ステーションに直接接続してインポートする。ソース・ステーション Nginx は、ドメイン名のためのサーバーブロックを準備し、client_max_body_size移転21g(参考)リバースプロキシとHTTPS大きな要請体の一部)。

灰色雲のサブドメインがソースステーションIPを暴露する

DNS only レコードは、ソースステーションの実際のアドレスに直接解析され、「隠されたソースステーション」のターゲットと衝突します。インポートが完了した後、レコードを削除するか、最初からインテルネットワークに直接接続することをお勧めします。

プログラムB:Cloudflareトンネル

トンネルは原発から。cloudflaredプロセス外出活動Cloudflare エッジに接続し、トンネルからトラフィックを回収します。公共ネットワーク IP (ホームブロード NAT、インネットサーバー) がない場合、または入力ポートを開くことを望まない場合に適しています:ファイアウォールは完全に入力を遮断し、ソースステーションの IP は自然に暴露されず、ソースステーションの Nginx と証明書は必要ありません。

ステップ 1: パネルでトンネルを作成して token を取る

Cloudflare パネルにアクセスするZero Trust(初回使用は初期化が必要で、Free プランでご利用いただけます)。
Networks → Tunnels → Create a tunnelコネクタの種類を選択Cloudflared名前(たとえば、aivory)。
作成したページには、長いトークンを含むインストールコマンドが表示されます(eyJh...トークンをコピーするだけで、次に環境変数としてコンテナに渡します。

ステップ2:compose Cloudflared サービスの追加

在 deploy/docker-compose.prod.yml 的 services追加(およびapp同級生):

  cloudflared:
    image: cloudflare/cloudflared:latest
    restart: unless-stopped
    command: tunnel run
    environment:
      TUNNEL_TOKEN: ${TUNNEL_TOKEN:?请在 .env 中设置 Cloudflare Tunnel token}
    networks:
      - internal
    depends_on:
      app:
        condition: service_healthy

在 .env中加入:

TUNNEL_TOKEN=eyJh...你的token...

ポイント :

cloudflared既存のプライベートネットワークに加入internal, 和appコンテナは直接相互接続し、帰源は宿泊機から出ません。
トンネルは純出駅接続です。cloudflared何も必要ないports映射する。
appサービスのports認められることから"80:8787"緊張する為"127.0.0.1:8787:8787": 公共のネットワークのトラフィックはすべてトンネルに移動し、ローカル 8787 リダイレクトリンクは管理者向けにバックアップインポートされます(以下を参照)。

docker compose -f docker-compose.prod.yml up -d
docker compose -f docker-compose.prod.yml logs -f cloudflared   # 看到 Registered tunnel connection 即连通

ステップ 3: Public hostname (ingress) を設定する

パネルの中のトンネルに戻る。Public Hostnameラベルページ、追加:

フィールド	值
Subdomain	`chat`
Domain	`example.com`
Type	`HTTP`
URL	`app:8787`

ingress 指向http://app:8787:cloudflared 与 app一緒にinternalサービス名で直接接続するネットワーク保存後、Cloudflare はブラウザがアクセスするオレンジクラウドの DNS レコードを自動的に作成しますhttps://chat.example.comAivory を開きます。

トンネルモードにおける実際の IP とストリームの制限

トンネルモードでは Nginx は不要で、実際の IP リンクは自動的に作成されます:Cloudflare エッジは訪問者の IP を書き込むX-Forwarded-For 与 CF-Connecting-IP,cloudflaredこんな風に送るapp;app正反対側は、cloudflaredコンテナのプライベートネットアドレス、信頼条件を満たすX-Forwarded-For右側の非オンラインエントリは、訪問者の本当のIPです。展開が完了すると、終了リストに従って1回確認できます。

Tunnel モードのバックアップインポート

トンネルトラフィックも同様にCloudflareの端を経て、リクエストの上限はオレンジ雲と完全に一致します。(Free/Pro 100MB 以降) 20GiB レベルのバックアップのインポートは依然として回避する必要があります: 前のステップで保存する127.0.0.1:8787サーバーのローカルコンピュータに直接接続してインポートするため、compose ではこのポートのマッピングを維持することをお勧めします。

2 プログラムの比較

サイズ	プロジェクトA:オレンジ雲代理	プログラムB:Cloudflareトンネル
公共ネットワーク IP / オープンポート	少なくとも443は必要です。	必要ない、入り口ゼロ
源泉部品	Nginx + 証明書(Full strict)	Cloudflared コンテナのみ
証明書運用	ソースステーションには、本物の証明書(certbot または Origin CA)が必要です。	ゼロ、エッジ証明書は Cloudflare によって管理されています
源泉隠し	オレンジクラウドはDNSを隠し、ファイアウォールのホワイトリストを追加することを推奨	自然隠し、防火壁が完全に閉じ込められる駅
本物のIPを復元	Nginx real_ip モジュールが必要です。	自動設定、設定不要
SSE 流式	正常(15s 心拍が限界を覆う超時間)	普通(左)
要求体上限	CF パッケージごとに(Free 100 MB)	同じ
バックアップ入力	内部接続または灰雲子域	本機直結`127.0.0.1:8787`
故障面	Nginx、証明書更新、CFの3つ	cloudflared プロセスと CF の両方

アドバイス:パブリックネットワークの IP があり、既に Nginx を実行している場合、オプション A 、新しいデプロイ、ホーム広さ、または証明書に触れない場合、オプション B。

リストの終了点検

終了後、すべてを繰り返す:

SSL/TLS モデル選択肢 A は Full (strict) (または、Flexible を明示的に受け入れ、リソースリンクを信頼できる) で、選択肢 B は設定する必要はありません。
Always Use HTTPS開設、訪問。http://chat.example.com301 から HTTPS へ
Rocket Loader閉鎖された。
Cache Rules:/api/*Bypass キャッシュルールは存在し、最前列にあります。
OAuth リリース(OAuth ログインを有効にしている場合):OAUTH_CALLBACK_BASE_URL外部に設定https://ドメイン名、OAuth プロバイダー側のリクエストアドレスが同期され、詳細を見るFAQ。
SSE 流式正常: メッセージを送信し、文字ごとに返信するには、書き込みマシン効果が表示されます。カードが長い時間が経過した後、セクション全体が飛び出した場合、まずソースステーション Nginx が欠落しているか確認してください。proxy_buffering off再度、キャッシュルールが適用されているかどうかを確認します。/api/*。
**ストリーム制限は、リアルIPで有効です。**プロジェクト A ソースステーション Nginx access log は、訪問者のパブリックネットワーク IP ではなく Cloudflare セグメントでなければならず、プロジェクト B は、2 つの異なるネットワーク (携帯電話のトラフィックとホームブロードバンドなど) からアクセスし、ストリーム制限数に影響を及ぼさないことを確認します。すべてのユーザーが共有ストリーム制限を見つけた場合は、real_ip 構成またはX-Forwarded-For転送する。
輸入通路のバックアップオンライン接続(オンライン接続)127.0.0.1:8787)またはグレークラウドサブドメインの手法を理解しているので、データを復元する必要がある場合に100MBの上限を見つけることはありません。
健康検査(外部配列を使用する場合):ルートへのGET /返す 200 は生存を表します。

障害時の一般的な考え方:まず Cloudflare リダイレクトソースステーションを回避します。curl http://127.0.0.1:8787/アプリ自体が正常であることを確認し、 Nginx、Cloudflare パネル構成を次々とチェックします。

前提条件:ドメイン名へのアクセス Cloudflare​

プロジェクトA:オレンジ雲代理​

ステップ 1: DNS レコードがオレンジ クラウドを開く​

ステップ 2: SSL/TLS 暗号化モードを選択する​

ステップ 3: ソース ステーション Nginx が実際の訪問者 IP を復元する​

SSE 長い接続:開箱で使えますが、API をキャッシュしないでください​

Cache Rules: API を回避し、静的リソースをキャッシュする​

パネルスイッチ:開くべきと閉じるべき​

リクエストの上限と「バックアップインポート」を回避​

プログラムB:Cloudflareトンネル​

ステップ 1: パネルでトンネルを作成して token を取る​

ステップ2:compose Cloudflared サービスの追加​

ステップ 3: Public hostname (ingress) を設定する​

トンネルモードにおける実際の IP と ストリームの制限​

Tunnel モードのバックアップインポート​

2 プログラムの比較​

リストの終了点検​