【補足３】Difyの高度なネットワーク設定ガイド (ポート変更・プロキシ対応・独自証明書)

この記事は、メイン記事『【構築】ConoHa VPSではじめるDifyコミュニティ版 導入・起動ガイド』やDocker関連ガイドの補足記事です。 Difyを標準設定とは異なるネットワーク環境で動作させるための、以下の高度な設定について解説します。

1. アクセスポートの変更: ホストサーバーの80番/443番ポートが他のサービスで使用されている場合に、Difyのアクセスポートを変更する方法。
2. プロキシサーバー経由での動作設定: 企業ネットワークなど、インターネットアクセスにプロキシサーバーを経由する必要がある環境でDifyを動作させるための設定。
3. 独自SSL証明書（オレオレ証明書など）の信頼設定: プロキシサーバーがSSL通信を検査する場合などに必要となる、Difyコンテナが独自証明書を信頼するための設定。

前提条件:

• Difyコミュニティ版がDocker Composeでデプロイされていること。
• 基本的なDockerおよびDocker Composeコマンド (cd, ls, cp, vi/nano, docker compose up -d, docker compose downなど) の知識があること。
• 作業はDifyのソースコードをクローンしたディレクトリ内の docker サブディレクトリで行います (cd dify/docker)。

1. Difyのアクセスポートを変更する

Difyはデフォルトでホストサーバーの 80 番ポート (HTTP) と 443 番ポート (HTTPS) を使用して外部からのアクセスを受け付けます。もしこれらのポートがホストサーバー上の他のWebサーバー（Apache, Nginxなど）によって既に使用されている場合は、Difyが使用するポート番号を変更する必要があります。

手順:

1..env ファイルを開く: dify/docker ディレクトリにある .env ファイルをテキストエディタで開きます。（存在しない場合は cp .env.example .env で作成）

cd dify/docker
vi .env # または nano .env

2.ポート番号の設定箇所を探す: ファイルの下の方にある EXPOSE_NGINX_PORT と EXPOSE_NGINX_SSL_PORT の行を探します。

# ------------------------------
# Docker Compose Service Expose Host Port Configurations
# ------------------------------
# Change the port mapping of the nginx container if port 80 is occupied.
EXPOSE_NGINX_PORT=80
# Change the https port mapping of the nginx container if port 443 is occupied.
EXPOSE_NGINX_SSL_PORT=443

3.ポート番号を変更する: EXPOSE_NGINX_PORT を任意のHTTP用ポート番号（例: 20080）に、EXPOSE_NGINX_SSL_PORT を任意のHTTPS用ポート番号（例: 20443）に変更します。使用するポート番号は、ホストサーバーで他のサービスが使用していない番号を選んでください（通常1024番以上）。

# ------------------------------
# Docker Compose Service Expose Host Port Configurations
# ------------------------------
# Change the port mapping of the nginx container if port 80 is occupied.
- EXPOSE_NGINX_PORT=80
+ EXPOSE_NGINX_PORT=20080
# Change the https port mapping of the nginx container if port 443 is occupied.
- EXPOSE_NGINX_SSL_PORT=443
+ EXPOSE_NGINX_SSL_PORT=20443

4.ファイルを保存してDifyを再起動: .env ファイルを保存し、docker compose down で一度コンテナを停止・削除してから、docker compose up -d で再起動します。

docker compose down
docker compose up -d

4.アクセス確認: ブラウザで http://<サーバーIP>:<変更後のHTTPポート> (例: http://<サーバーIP>:20080) にアクセスしてDifyの画面が表示されるか確認します。（SSL設定後は https://<ドメイン名>:<変更後のHTTPSポート> で確認）

2. プロキシサーバー経由でDifyを動作させる

企業ネットワークなど、インターネットへのアクセスにHTTP/HTTPSプロキシサーバーを経由する必要がある環境では、Difyの各コンテナ（特に外部のLLM APIなどにアクセスする api, worker, plugin_daemon コンテナ）がプロキシサーバーを利用できるように設定する必要があります。また、内部通信（例: ssrf_proxy から sandbox へのアクセス）がプロキシを経由しないように除外設定も必要です。

手順:

1..env ファイルにプロキシ情報を追記:dify/docker ディレクトリの .env ファイルの末尾に、使用するプロキシサーバーの情報を追記します。環境変数名が既存のものと衝突しないように、接頭辞 MY_ を付けて定義します。MY_NO_PROXY には、プロキシを経由させたくない内部コンテナのサービス名やIPアドレス範囲をカンマ区切りで指定します。

# .env ファイルの末尾に追記

# Proxy Settings
MY_HTTP_PROXY=http://<プロキシサーバーのIP or ホスト名>:<ポート>
MY_HTTPS_PROXY=http://<プロキシサーバーのIP or ホスト名>:<ポート>
# プロキシ認証が必要な場合 (不要ならコメントアウト)
# MY_HTTP_PROXY=http://<ユーザー名>:<パスワード>@<プロキシIP>:<ポート>
# MY_HTTPS_PROXY=http://<ユーザー名>:<パスワード>@<プロキシIP>:<ポート>

# プロキシ除外設定 (Difyの内部コンテナは基本的に除外)
MY_NO_PROXY=localhost,127.0.0.1,.local,host.docker.internal,weaviate,qdrant,pgvector,pgvecto-rs,chroma,milvus-standalone,opensearch,elasticsearch,redis,db,sandbox,ssrf_proxy,plugin_daemon,api,worker,web,nginx,172.16.0.0/12,192.168.0.0/16,10.0.0.0/8

• <プロキシサーバーのIP or ホスト名>:<ポート> は実際の環境に合わせて変更してください。
• MY_NO_PROXY は、一般的なローカルアドレス、Docker内部ネットワークで使われがちなプライベートIP範囲、およびDifyの主要なサービス名を列挙しています。環境に応じて調整が必要な場合があります。

2.docker-compose.yaml を編集: dify/docker ディレクトリの docker-compose.yaml ファイルを開き、外部インターネットにアクセスする必要があるサービスの environment: セクションに、.env で定義したプロキシ設定を読み込むように追記します。

vi docker-compose.yaml # または nano docker-compose.yaml

最低限、以下のサービスには設定が必要です。

• api

• worker
• plugin_daemon (プラグイン機能を使う場合)
• certbot (Let’s Encrypt を使う場合)

以下は api サービスへの追記例です。environment: ブロック内にインデントを合わせて追記してください。他のサービスにも同様に追加します。

services:
  api:
    image: langgenius/dify-api:${DIFY_VERSION:-latest}
    restart: always
    environment:
      <<: *shared-api-worker-env
      MODE: api
      # ... (既存の環境変数) ...
+     HTTP_PROXY: ${MY_HTTP_PROXY:-} # 末尾の ":-" は .env に定義がない場合に空にするための記述
+     HTTPS_PROXY: ${MY_HTTPS_PROXY:-}
+     NO_PROXY: ${MY_NO_PROXY:-}
    depends_on:
      - db
      - redis
    # ... (以下略) ...

3.ssrf_proxy の設定を編集 (Squid):ssrf_proxy コンテナは内部でSquidプロキシサーバーを動かしています。このSquid自体が外部へのアクセス（例: プラグインからのHTTPリクエスト）を行う際に、上位のプロキシサーバーを経由するように設定します。

vi ssrf_proxy/squid.conf.template
ファイルの中ほどにある # upstream proxy というコメントの下あたりに、cache_peer ディレクティブを追加します。また、never_direct ディレクティブで内部コンテナ(sandboxなど)へのアクセスは上位プロキシを経由しないようにします。

# cache_dir ufs /var/spool/squid 100 16 256

# upstream proxy, set to your own upstream proxy IP to avoid SSRF attacks
# cache_peer 172.1.1.1 parent 3128 0 no-query no-digest no-netdb-exchange default

+ # --- 上位プロキシ設定 ---
+ # cache_peer <上位プロキシIP> parent <ポート> 0 no-query no-digest name=myproxy login=<ユーザー名>:<パスワード> # 認証が必要な場合
+ cache_peer ${MY_HTTP_PROXY_HOST} parent ${MY_HTTP_PROXY_PORT} 0 no-query no-digest name=myproxy # 認証不要な場合 (別途 .env で MY_HTTP_PROXY_HOST と PORT を定義)
+ acl internal_services dstdomain sandbox weaviate qdrant # プロキシ除外対象 (内部コンテナ)
+ never_direct deny internal_services
+ never_direct allow all # 上記以外は上位プロキシ(myproxy)を経由
+ # --- ここまで ---

forwarded_for delete

• 注意: squid.conf.template の編集は少し複雑です。上記の例は基本的なものであり、実際のプロキシ環境（認証の有無など）に合わせて調整が必要です。.env でプロキシホストとポートを分割して定義 (MY_HTTP_PROXY_HOST, MY_HTTP_PROXY_PORT) し、それを ${...} で参照する形にすると管理しやすいでしょう。

4.ファイルを保存してDifyを再起動: すべてのファイルを保存し、docker compose down でコンテナを停止・削除してから、docker compose up -d で再起動して設定を反映させます。

docker compose down
docker compose up -d

5.動作確認: Difyにログインし、外部LLM（OpenAIなど）のAPIキーを設定したり、プラグインを追加したりして、外部への通信が正常に行えるか確認します。エラーが出る場合は、各コンテナのログ (docker compose logs api, docker compose logs worker など) を確認して原因を調査します。

3. 独自SSL証明書（オレオレ証明書など）を信頼させる

企業内プロキシサーバーがSSL通信の内容を検査（SSLインスペクション）している場合、プロキシサーバーが発行した中間CA証明書（または自己署名証明書）をDifyのコンテナ（特に api, worker, plugin_daemon）に信頼させる必要があります。これを行わないと、外部APIへのHTTPS通信時に「証明書検証エラー (CERTIFICATE_VERIFY_FAILED)」が発生します。

手順:

1.信頼させたい証明書ファイルを用意: プロキシサーバーの管理者などから、信頼させるべきCA証明書ファイル（通常は .pem または .crt 形式）を入手します。複数ある場合は連結して1つのファイルにします。ここでは例として my_corp_ca.crt とします。

2.証明書ファイルを配置: 入手した証明書ファイルを、ホストサーバー上のアクセスしやすい場所（例: Difyソースコードのルートディレクトリ直下に ssl_certs フォルダを作成して、その中に置く）に配置します。

# dify ソースコードのルートディレクトリで実行
mkdir ssl_certs
cp /path/to/my_corp_ca.crt ssl_certs/

3.docker-compose.yaml を編集:docker-compose.yaml を開き、外部HTTPS通信を行うコンテナ (api, worker, plugin_daemon など) に以下の設定を追加します。

• volumes:: ホストに配置した証明書ファイルを、コンテナ内の証明書ストアディレクトリにマウントします。entrypoint:: コンテナ起動時に update-ca-certificates コマンドを実行し、マウントした証明書をシステムの信頼ストアに追加するように変更します。environment:: Python (requestsライブラリなど) がシステムの証明書ストアを参照するように環境変数を設定します。
以下は api サービスへの追記例です。worker や plugin_daemon にも同様の変更を加えます。

services:
api:
# … (image, restart, existing environment, depends_on etc.) …
+ environment:
+ # … (既存の環境変数) …
+ # Python requestsライブラリなどがシステムのCAストアを参照するように設定
+ REQUESTS_CA_BUNDLE: /etc/ssl/certs/ca-certificates.crt
+ # (プロキシ設定も必要な場合はここに追記)
+ # HTTP_PROXY: ${MY_HTTP_PROXY:-}
+ # HTTPS_PROXY: ${MY_HTTPS_PROXY:-}
+ # NO_PROXY: ${MY_NO_PROXY:-}
volumes:
– ./volumes/app/storage:/app/api/storage
+ # ホストの証明書ファイルをコンテナ内の所定の場所にマウント
+ – ./../ssl_certs/my_corp_ca.crt:/usr/local/share/ca-certificates/my_corp_ca.crt:ro
+ # コンテナ内のPythonライブラリが使う可能性のあるパスにもシンボリックリンクまたはコピー
+ # (requestsが参照するcertifiパッケージのパスなど。イメージによって異なる場合あり)
+ # – ./../ssl_certs/my_corp_ca.crt:/usr/local/lib/python3.x/site-packages/certifi/cacert.pem:ro # (これは一例)
+ entrypoint:
+ – /bin/sh
+ – -c
+ – |
+ # コンテナ起動時に証明書ストアを更新
+ update-ca-certificates
+ # 元々のエントリポイントスクリプトを実行
+ exec /entrypoint.sh api
networks:
– ssrf_proxy_network
– default
# … (以下略) …

4.ファイルを保存してDifyを再起動: docker-compose.yaml を保存し、docker compose down と docker compose up -d --build でコンテナを再構築・再起動します（--build が必要）。

docker compose down
docker compose up -d --build