Dify トラブル解決

DifyのHTTPリクエストが120秒で切れる原因｜SSRF_DEFAULT_READ_TIME_OUTを伸ばしても直らない理由と対処法

セルフホスト（Docker）のDifyで、HTTPリクエストノードから時間のかかる外部APIを呼ぶと、ちょうど120秒で失敗する。SSRF_DEFAULT_READ_TIME_OUT を600に伸ばしても変わらない。この症状の原因は、Difyに同梱されているプロキシ「Squid」の設定ファイルに、タイムアウトが直接書き込まれていることでした。この記事では、Difyのソースコードを読んで原因を突き止めた過程と、今すぐできる対処法、公式への修正提案の状況をまとめます。

1. 症状：何を設定しても120秒で失敗する

DifyのGitHubには、同じ症状の報告があります（Issue #31098、2026年1月）。報告者は、動画を生成するのに10分以上かかる社内のAPIをHTTPリクエストノードから呼んでいました。Difyを更新したあと、毎回ちょうど120秒で処理が打ち切られるようになったそうです。

Reached maximum retries (0) for URL ... after 120s

報告者は .env で次のように設定していましたが、症状は変わりませんでした。

SSRF_DEFAULT_TIME_OUT=600
SSRF_DEFAULT_CONNECT_TIME_OUT=30
SSRF_DEFAULT_READ_TIME_OUT=600
SSRF_DEFAULT_WRITE_TIME_OUT=600

HTTPリクエストノード自体のタイムアウトも、上限の設定（HTTP_REQUEST_MAX_READ_TIMEOUT）は既定で600秒です。つまり、Difyのアプリ側の設定をすべて伸ばしても、どこか別の場所で120秒に制限されている状態です。

この記事の対象

Docker Composeで動かすセルフホスト版のDifyが対象です。記事中のファイルの場所や設定値は、2026年9月27日時点のDify公式リポジトリ（mainブランチ、最新リリースは1.17.1）で確認したものです。Dify Cloud（公式のクラウド版）は対象外です。

2. 原因：タイムアウトが「二階建て」になっている

セルフホスト版のDifyでは、HTTPリクエストノードやツールが外部に通信するとき、必ず ssrf_proxy というコンテナを通ります。中身はSquidというプロキシで、社内ネットワークなどへの不正なアクセス（SSRF）を防ぐためのものです。

[api / worker コンテナ] --(1)--> [ssrf_proxy コンテナ（Squid）] --(2)--> [外部のAPI]

この2つの区間に、それぞれ別のタイムアウトがあります。

区間	設定する場所	.envで変えられるか
(1) Difyのアプリ → Squid	`SSRF_DEFAULT_*_TIME_OUT`、HTTPリクエストノードの設定	変えられる
(2) Squid → 外部のAPI	`docker/ssrf_proxy/squid-common.conf.template` に直接記述	変えられない

SSRF_DEFAULT_READ_TIME_OUT という名前から、プロキシ（SSRF）のタイムアウトを伸ばす設定に見えます。しかしDifyのソースコード（api/core/helper/ssrf_proxy.py）を読むと、この値が使われているのは(1)の区間、つまりDifyのアプリがSquidに接続するときのタイムアウトだけでした。(2)の区間には効きません。

Squid側に書かれている値

docker/ssrf_proxy/squid-common.conf.template には、次のように数値が直接書かれています（主なものを抜粋）。

設定	Difyの値	Squidの既定値	意味
`read_timeout`	2分	15分	相手からデータが届かない状態がこの時間続くと、通信を打ち切る
`client_lifetime`	5分	1日	1つの接続を保てる最大の時間
`request_timeout`	2分	5分	接続してからリクエストのヘッダーを受け取り終えるまでの待ち時間
`connect_timeout`	30秒	—	相手のサーバーに接続するまでの待ち時間

Squidの既定値は、Squid公式ドキュメントの値です。120秒で切れる直接の原因は read_timeout 2 minutes です。外部のAPIが処理中で何も返さない時間が2分続くと、Squidが通信を打ち切ります。

さらに client_lifetime 5 minutes があるため、仮に途中でデータが少しずつ返ってきても、1つの接続は5分で必ず切られます。Squid公式ドキュメントでは、client_lifetime は「最後の手段としてのみ変更すべき」とされていて、既定値は1日です。Difyではこれがかなり短く設定されています。

これらの値は、2026年1月にマージされたPR #30146（Squidの設定強化）で追加されました。Issue #31098で「Difyを更新したら120秒で切れるようになった」と報告されているのは、このためだと考えられます。

3. 対処法：今すぐできる3つの方法

2026年9月27日時点では、Squid側のタイムアウトを .env で変える方法は公式には用意されていません。現実的な対処法は次の3つです。

方法	手軽さ	注意点
① Squidの設定ファイルを直接書き換える	数行の変更	Difyを更新するたびに書き換え直しが必要
② 特定の宛先だけプロキシを通さない	環境変数の追加	その宛先へのSSRF対策が効かなくなる
③ API側を「受付＋結果の確認」の形に変える	API側の改修が必要	長い処理には最も確実

① Squidの設定ファイルを直接書き換える

docker/ssrf_proxy/squid-common.conf.template の該当行を、必要な長さに書き換えます。10分待ちたい場合の例です。

read_timeout 10 minutes
client_lifetime 15 minutes

このファイルはコンテナにそのまま読み込まれ、起動時に設定ファイルに展開されます。書き換えたら、docker フォルダで ssrf_proxy を作り直してください。

docker compose up -d --force-recreate ssrf_proxy

あわせて、Difyのアプリ側のタイムアウト（.env の SSRF_DEFAULT_READ_TIME_OUT や、HTTPリクエストノードのタイムアウト設定）も、待ちたい時間以上にしておきます。どちらか短いほうで切れるためです。

更新時の上書きに注意

このファイルはDifyのリポジトリに含まれているため、git pull で更新すると、書き換えた部分がぶつかったり元に戻ったりします。変更した箇所をメモしておき、更新のたびに確認してください。また、同じファイルはエージェント用のプロキシ（agent_ssrf_proxy）でも読み込まれるため、両方に効きます。

② 特定の宛先だけプロキシを通さない

Issue #31098の報告者が使っていた回避策です。docker-compose.yaml の api と worker に NO_PROXY を追加し、時間のかかるAPIの宛先だけSquidを通さないようにします。

api:
  environment:
    NO_PROXY: localhost,127.0.0.1,10.0.0.5

worker:
  environment:
    NO_PROXY: localhost,127.0.0.1,10.0.0.5

IPアドレスは例です。報告者によると、これで結果が返るまで待てるようになったそうです。ただし、Squidを通らない分、その宛先に対してはSSRF対策が効かなくなります。自分で管理している社内のAPIなど、信頼できる宛先だけに限定してください。

③ API側を「受付＋結果の確認」の形に変える

10分以上かかるような処理は、1回のリクエストで結果を待つ設計そのものに無理があります。API側を次のような形に変えられるなら、それが最も確実です。

最初のリクエストでは処理を受け付けて、すぐに「受付番号」を返す
Difyのワークフローで、一定の間隔を空けて「受付番号の処理は終わったか」を確認する
終わっていたら結果を取得する

この形なら、1回1回のリクエストは短く終わるので、Squidのタイムアウトに引っかかりません。

4. 公式での修正の状況

この問題は、DifyのGitHubですでに知られています。

時期	出来事
2026年1月4日	PR #30146がマージされ、Squidのタイムアウトが直接書き込まれる
2026年1月16日	Issue #31098で「120秒で必ず切れる」と報告される（その後クローズ）
その後	PR #32483で、`request_timeout` と `read_timeout` を環境変数で変えられるようにする修正が提案される
2026年5月26日	PR #32483が、3か月以上放置されCIも失敗していたため、マージされずにクローズ
2026年9月27日時点	mainブランチでも `read_timeout 2 minutes` のまま。未解決

PR #32483のクローズは、修正の方向性を否定されたわけではありません。メンテナーは「まだ必要なら、CIを直した新しいPRを歓迎する」とコメントしています。

PR #32483の修正だけでは足りない点

筆者がソースを読んで気づいた点が2つあります。

client_lifetime が対象に入っていない：read_timeout を伸ばしても、client_lifetime 5 minutes が残る限り、接続は5分で切られます。10分以上待ちたい場合はこちらも変える必要があります
環境変数が未設定のときに壊れる可能性：Difyの起動スクリプトは、設定ファイル内の ${変数名} を環境変数の値に置き換えます。変数が設定されていないと、read_timeout seconds のように数値が空の不正な設定になり、Squidが起動に失敗します。起動スクリプト側で既定値を持たせる必要があり、CIの失敗はこれが原因だった可能性があります

Issueを立てる前に、既存の報告を探す

筆者は最初、この問題を「設計上の不備」として新しくIssueを立てようとしていました。投稿の直前に既存のIssueとPRを検索したところ、同じ内容がすでに報告済みだと分かりました。Difyのリポジトリでは、重複したIssueや英語以外のIssueはクローズされます。OSSに報告するときは、クローズ済みのものも含めて検索してから投稿するのがおすすめです。

5. よくある質問（FAQ）

Q. Dify Cloud（公式のクラウド版）でも同じですか？

A. この記事で扱ったのはセルフホスト版のDocker構成です。Dify Cloudでは自分でSquidの設定を変えられないため、長い処理は③の「受付＋結果の確認」の形にするのが現実的です。

Q. 120秒ではなく5分ちょうどで切れます。

A. 外部のAPIが途中で少しずつデータを返している場合、read_timeout には引っかからず、client_lifetime 5 minutes で切れている可能性があります。①の方法で client_lifetime も伸ばしてください。

Q. 設定ファイルを書き換えたのに変わりません。

A. ssrf_proxy コンテナを作り直していない可能性があります。設定は起動時に展開されるため、docker compose up -d --force-recreate ssrf_proxy を実行してください。また、Difyのアプリ側のタイムアウト（SSRF_DEFAULT_READ_TIME_OUT やノードの設定）が短いままになっていないかも確認してください。

Q. プロキシを外してしまえば簡単では？

A. SquidはSSRF（Difyを踏み台にした社内ネットワークへの不正アクセス）を防ぐためのものです。外部の人も使うDifyでプロキシを外すのは危険です。外すとしても、②のように信頼できる宛先だけに限ってください。