リバースプロキシとHTTPS

アイボリーのapp容器は8787前端のSPAと同端のSPA/apiバックエンドは、HTTPのみです。生産環境は、TLSの終了を担当するリバースプロキシの層をその前に置くことをお勧めします。このページでは、NginxとCaddyの2つの完全な構成セットを直接挿入し、それぞれがなぜそう書かれているのかを説明します。

なぜ CORS を設定する必要はありませんか?

フロントエンドとAPIは、同じプロセス、同じポートでサーバー化され、ブラウザの視点から常に同じソースです。どのドメイン名でアクセスするか、どのドメイン名を使用するかは不要です。PUBLIC_ORIGINドメイン名で CORS ホワイトリストを設定する必要はありません。ALLOWED_ORIGINSあなたが先頭に火を投げ込んだときだけ異なる源展開形態では意味があり、単一容器の展開はできません。

開始前に:ポートマッピングの調整

迅速な展開compose ドキュメントは、デフォルトappホーム > ホーム > ホーム > ホーム > ホーム > 80 ("80:8787"同一マシンに Nginx/Caddy を追加する場合、80/443 を逆代に譲り、app再生回線を聴くだけに変更する:

# deploy/docker-compose.prod.yml 中 app 服务的 ports 段
ports:
  - "127.0.0.1:8787:8787"

修正実施docker compose -f docker-compose.prod.yml up -d再建appコンテナ、その後反世代統一に転送http://127.0.0.1:8787。

健康検査

根の道へGET /生存を表す 200 を返すと、直接代替またはクラウド負荷バランスの健康検査検出パスとして使用できます。

重要な前提条件:流式出力行 SSE

Aivory の AI 応答は SSE (Server-Sent Events) を介してストリーミングされます。ウェブソケットなしだから、何も必要ない。Upgrade関連構成サーバー側は 15 秒ごとに ping ハートを送信し、中間エージェントがフラッシュで接続を断ち切るのを防ぐ。

応答バッファの停止エージェントがバッファに反応する場合、トークンは大きなブロックに保存され、ブラウザに吐き出し、プリントマシン効果は直接消え、「カードが長い後、全体が飛び出します」と表現されます。
読書時間の延長: ディプリサーチまたは長いツールチェーンの回答は数十分間続くことがあります。

以下の2つの設定には、これらの処理が含まれています。

プログラム1:Nginx

完全配置

保存する為/etc/nginx/sites-available/aivory.conf置き換えchat.example.comあなたのドメイン名:

# HTTP:仅用于 certbot 验证与跳转 HTTPS
server {
    listen 80;
    listen [::]:80;
    server_name chat.example.com;

    # certbot webroot 验证路径(用 --nginx 插件时可省略)
    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

# HTTPS 主站
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;   # nginx < 1.25.1 请删除此行,改为在上面两行 listen 末尾追加 http2
    server_name chat.example.com;

    ssl_certificate     /etc/letsencrypt/live/chat.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/chat.example.com/privkey.pem;

    # 普通上传默认上限 50MB(MAX_UPLOAD_BYTES),此处留出余量。
    # 管理员备份导入可达 20GiB,见下文「大请求体」一节。
    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 与协议 ---
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

再起動および再起動:

sudo ln -s /etc/nginx/sites-available/aivory.conf /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

各項目説明

指示	役割
`proxy_pass http://127.0.0.1:8787`	転送へ`app`コンテナ、SPAおよび`/api`同じアップストリームで、場所を分ける必要はありません。
`proxy_buffering off`	応答バッファをオフにすると、SSEのすべてのイベントがすぐにブラウザに伝わります。
`proxy_read_timeout 3600s`	読み過ぎ時間は1時間までリラックスします。サービス側の15秒ごとに心拍数がほとんどの空きシーンをカバーし、エージェントが押しつぶすことによって長い回答を避けるための追加のポケットです。
`proxy_http_version 1.1`	アップストリーム HTTP/1.1 を使用して、長い接続をサポートし、ストリーム転送の前提条件
`proxy_set_header Connection ""`	清空`Connection`ヘッド、アップストリームと keepalive を維持し、短い接続に降格されるのを避ける
`client_max_body_size 100m`	リクエストの上限。Nginx はデフォルトで 1MB のみで、アップロードされたファイルが直接返されます 413
`proxy_set_header Host $host`	オリジナルのドメイン名を転送します。ホストが正しく転送されている限り、単一コンテナ同源アーキテクチャのいかなるドメイン名も使用できます(すべての逆代がデフォルト)
`X-Real-IP` / `X-Forwarded-For`	実際のクライアント IP を送信し、限界ストリームに直接関連し、以下のセクションを参照
`X-Forwarded-Proto $scheme`	裏側の外側はHTTPSです。

certbot で証明書を申請する

# Debian / Ubuntu
sudo apt install certbot python3-certbot-nginx

# 自动修改 Nginx 配置并签发证书
sudo certbot --nginx -d chat.example.com

# 验证自动续期
sudo certbot renew --dry-run

--nginxプラグインはドメイン名の検証を自動的に完了し、書き込みします。ssl_certificateプロフィールを完全に手動で制御したい場合は、webroot モードに切り替えます。

sudo mkdir -p /var/www/certbot
sudo certbot certonly --webroot -w /var/www/certbot -d chat.example.com

認証書が発行された後、/etc/letsencrypt/live/chat.example.com/上記のコースと一致しています。

プロジェクト2:Caddy

Caddy は Let's Encrypt 証明書を自動的に申請し、更新し、自動的に HTTP を HTTPS に転送します。Caddyfile必要なのは3行:

chat.example.com {
    reverse_proxy 127.0.0.1:8787
}

sudo systemctl reload caddy

フラッシュ・インターバルについて

Caddy v2 が検出されましたContent-Type: text/event-stream応答バッファは自動的に無効になりますので、上記の3行は通常、ボックスを開きます。あなたのバージョンが古い場合、またはバッファを導入する他の中間層が重なっている場合、明示的にシャットダウンできます:

chat.example.com {
    reverse_proxy 127.0.0.1:8787 {
        flush_interval -1
    }
}

flush_interval -1クライアントに1バイトずつ書き込むと、 Nginx に相当します。proxy_buffering off。

Caddy はデフォルトではリクエストサイズを制限しません。X-Forwarded-Forしたがって、ファイルのアップロード、バックアップインポート、実際の IP は追加の設定を必要としません。

ビッグリクエスト:アップロードとバックアップインポート

Aivoryには2種類の大要請体があり、逆世代です。client_max_body_size別々に扱う:

シーン	サービス上限	環境変数に対応	提案
一般文書/文書のアップロード	デフォルト 50MB	`MAX_UPLOAD_BYTES`	`client_max_body_size 100m`覆われている。
管理者バックアップ入力	デフォルト 20GiB	`MAX_BACKUP_BYTES`	下の2つの方法

管理者が後ろにいるバックアップ入力ファイル容量は最大20GBで、100m二つの実践:

暫定的な制限の拡大: 取client_max_body_size替わり21g 并 nginx -s reload入力完了後に変更を再開します. 大型ドキュメントシーンは、同時に追加することを推奨します。proxy_request_buffering offNginx 側面をリダイレクトし、まずファイル全体をローカルディスクにバッファリングしないようにします。
**インターネット接続(推奨)**サーバー本体または内部ネットワークへの直接アクセスhttp://127.0.0.1:8787輸入を実行し、逆世代の量と超時間の制限を完全に回避する。

サービス自体の上限MAX_UPLOAD_BYTES / MAX_BACKUP_BYTESコントロール、詳細進階環境変数。

リアルなIPと限界

Aivory は、クライアント IP のメンテナンス制限に基づいてストリームをカウントします(カウントは Redis に格納されます)。

直接接続が内部ネットワークまたは回路アドレスである場合のみ(つまり、実際の要求は、あなたが配置した逆世代から来ている)X-Forwarded-For / X-Real-IPそして取る。X-Forwarded-For 中右側の非オンライン記事本物のIPです。
ネットのアドレスは、これらのアドレスは、全て無視TCP対エンドアドレスを直接使用するため、公衆ネット攻撃者が偽造するX-Forwarded-For他人のIPを偽装することはできません。

この規則は、運用についての意味:

X-Forwarded-Forを適切に追加する必要があります。

逆代が設定されない場合proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_forすべてのリクエストは、バックエンドで自分自身のIPから来ています。サイト全体のユーザーは、同じストリーム制限数を共有します: 1 つでストリーム制限を起動し、全員で制限されます。上記の Nginx 設定には正しい書き方があり、Caddy のデフォルト行動は正しいです。

CloudFlare シナリオ流通経路が変わる。访客 -> Cloudflare -> 源站 Nginx -> app, ソースステーション Nginx が見る対側は Cloudflare ノードです。 Nginx の real_ip モジュールが必要で、Cloudflare ベースのダウンロードCF-Connecting-IPまず、実際の訪問者IPを復元し、次に上記のリダイレクトリンクにアクセスします。

# 在 http 或 server 块中声明信任的 Cloudflare 回源网段(节选,完整列表见 Cloudflare 官方发布)
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
# ...其余 Cloudflare 网段...
real_ip_header CF-Connecting-IP;

こんな$remote_addr実際の訪問者IP$proxy_add_x_forwarded_for追加された値も正しいです。完全なセグメントリストのメンテナンスと段階的な設定が表示されます。Cloudflare アクセス。

HTTPSは使えないの?

Aivory は非安全なコンテンツ(純HTTP)で完全に利用可能である:アプリ内のリクエスト署名アルゴリズムは純JSリクエストを実装し、ブラウザが HTTPS でしか開かない暗号化インターフェイスに依存しない。

HTTPSを有効にすることを強くお勧めします。

HTTPとは、ログイン証明書、会話のコンテンツがすべてチェーンに流れ、中間のノードがすべて盗聴または変換できることを意味します。ドメイン名があれば、上記の任意の設定を数分間使用してHTTPSにオンラインすることができます。

よくある質問チェック

現象	理由	処理
答えは無流式で、カートンが現れる。	反発反応バッファ	Nginx 確認`proxy_buffering off`中央に他のバッファがあるかどうかをチェックする(例えば、一部のCDNなど)
答えは中途半端に。	読書時間が短すぎる	確認`proxy_read_timeout 3600s`CDNを通過した場合、CDNの空き時間チェックを同期
書類の書き込み 413	要求の上限が小さい。	拡大`client_max_body_size`
バックアップインポート失敗	ファイル上限を超える	暫定的に拡大`21g`ポート 8787 に直接接続します。
すべてのユーザーが同時に制限されます。	`X-Forwarded-For`間違った追加	上記の補足`proxy_set_header`二行
Cloudflare でバックストリームを CF ノードで IP メーター	ソースステーションが本物のIPを復元しない	real_ip モジュール + を設定する`CF-Connecting-IP`見るCloudflare アクセス

開始前に:ポートマッピングの調整​

重要な前提条件:流式出力行 SSE​

プログラム1:Nginx​

完全配置​

各項目説明​

certbot で証明書を申請する​

プロジェクト2:Caddy​

ビッグリクエスト:アップロードとバックアップインポート​

リアルなIPと限界​

HTTPSは使えないの?​

よくある質問チェック​