HTTP node Reached maximum retries (3) #7070

Closed
opened 2026-02-21 18:18:42 -05:00 by yindo · 7 comments
Owner

Originally created by @yuhp-zts on GitHub (Dec 5, 2024).

Self Checks

  • This is only for bug report, if you would like to ask a question, please head to Discussions.
  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
  • [FOR CHINESE USERS] 请务必使用英文提交 Issue,否则会被关闭。谢谢!:)
  • Please do not modify this template :) and fill in all the required fields.

Dify version

0.11.2

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

The agent works fine under the agent studio, but when calling the agent's API at the HTTP node, an error occurs. The squid.conf.template file settings are correct.
(1)agent works well
image

(2)http node raise error
image

(3)squid.conf.template:The agent's API complies with the required rules :http://10.26.xx.xx:8888/

 acl localnet src 0.0.0.1-0.255.255.255	# RFC 1122 "this" network (LAN)
acl localnet src 10.0.0.0/8		# RFC 1918 local private network (LAN)
acl localnet src 100.64.0.0/10		# RFC 6598 shared address space (CGN)
acl localnet src 169.254.0.0/16 	# RFC 3927 link-local (directly plugged) machines
acl localnet src 172.16.0.0/12		# RFC 1918 local private network (LAN)
acl localnet src 192.168.0.0/16		# RFC 1918 local private network (LAN)
acl localnet src fc00::/7       	# RFC 4193 local private network range
acl localnet src fe80::/10      	# RFC 4291 link-local (directly plugged) machines

acl SSL_ports port 443
acl Safe_ports port 80		# http
acl Safe_ports port 21		# ftp
acl Safe_ports port 443		# https
acl Safe_ports port 70		# gopher
acl Safe_ports port 210		# wais
acl Safe_ports port 1025-65535	# unregistered ports
acl Safe_ports port 280		# http-mgmt
acl Safe_ports port 488		# gss-http
acl Safe_ports port 591		# filemaker
acl Safe_ports port 777		# multiling http
acl HTTP_ports port 80 8888
acl CONNECT method CONNECT
http_access deny !Safe_ports
http_access allow Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow HTTP_ports
http_access deny !HTTP_ports
http_access allow localhost manager
http_access allow localnet
http_access deny manager
http_access allow localhost
include /etc/squid/conf.d/*.conf
http_access deny all

################################## Proxy Server ################################
http_port ${HTTP_PORT}
coredump_dir ${COREDUMP_DIR}
refresh_pattern ^ftp:		1440	20%	10080
refresh_pattern ^gopher:	1440	0%	1440
refresh_pattern -i (/cgi-bin/|\?) 0	0%	0
refresh_pattern \/(Packages|Sources)(|\.bz2|\.gz|\.xz)$ 0 0% 0 refresh-ims
refresh_pattern \/Release(|\.gpg)$ 0 0% 0 refresh-ims
refresh_pattern \/InRelease$ 0 0% 0 refresh-ims
refresh_pattern \/(Translation-.*)(|\.bz2|\.gz|\.xz)$ 0 0% 0 refresh-ims
refresh_pattern .		0	20%	4320


# 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

################################## Reverse Proxy To Sandbox ################################
http_port ${REVERSE_PROXY_PORT} accel vhost
cache_peer ${SANDBOX_HOST} parent ${SANDBOX_PORT} 0 no-query originserver
acl src_all src all
http_access allow src_all

✔️ Expected Behavior

No response

Actual Behavior

No response

Originally created by @yuhp-zts on GitHub (Dec 5, 2024). ### Self Checks - [X] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [X] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [X] I confirm that I am using English to submit this report (我已阅读并同意 [Language Policy](https://github.com/langgenius/dify/issues/1542)). - [X] [FOR CHINESE USERS] 请务必使用英文提交 Issue,否则会被关闭。谢谢!:) - [X] Please do not modify this template :) and fill in all the required fields. ### Dify version 0.11.2 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce The agent works fine under the agent studio, but when calling the agent's API at the HTTP node, an error occurs. The squid.conf.template file settings are correct. (1)agent works well ![image](https://github.com/user-attachments/assets/fb5a19c5-1692-4bb7-9766-390d4fb776a7) (2)http node raise error ![image](https://github.com/user-attachments/assets/62f1c73c-7eca-4494-bb22-bdad60fa2070) (3)squid.conf.template:The agent's API complies with the required rules :http://10.26.xx.xx:8888/ ``` acl localnet src 0.0.0.1-0.255.255.255 # RFC 1122 "this" network (LAN) acl localnet src 10.0.0.0/8 # RFC 1918 local private network (LAN) acl localnet src 100.64.0.0/10 # RFC 6598 shared address space (CGN) acl localnet src 169.254.0.0/16 # RFC 3927 link-local (directly plugged) machines acl localnet src 172.16.0.0/12 # RFC 1918 local private network (LAN) acl localnet src 192.168.0.0/16 # RFC 1918 local private network (LAN) acl localnet src fc00::/7 # RFC 4193 local private network range acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl HTTP_ports port 80 8888 acl CONNECT method CONNECT http_access deny !Safe_ports http_access allow Safe_ports http_access deny CONNECT !SSL_ports http_access allow HTTP_ports http_access deny !HTTP_ports http_access allow localhost manager http_access allow localnet http_access deny manager http_access allow localhost include /etc/squid/conf.d/*.conf http_access deny all ################################## Proxy Server ################################ http_port ${HTTP_PORT} coredump_dir ${COREDUMP_DIR} refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern \/(Packages|Sources)(|\.bz2|\.gz|\.xz)$ 0 0% 0 refresh-ims refresh_pattern \/Release(|\.gpg)$ 0 0% 0 refresh-ims refresh_pattern \/InRelease$ 0 0% 0 refresh-ims refresh_pattern \/(Translation-.*)(|\.bz2|\.gz|\.xz)$ 0 0% 0 refresh-ims refresh_pattern . 0 20% 4320 # 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 ################################## Reverse Proxy To Sandbox ################################ http_port ${REVERSE_PROXY_PORT} accel vhost cache_peer ${SANDBOX_HOST} parent ${SANDBOX_PORT} 0 no-query originserver acl src_all src all http_access allow src_all ``` ### ✔️ Expected Behavior _No response_ ### ❌ Actual Behavior _No response_
yindo added the 🐞 bug label 2026-02-21 18:18:42 -05:00
yindo closed this issue 2026-02-21 18:18:42 -05:00
Author
Owner

@dosubot[bot] commented on GitHub (Dec 5, 2024):

The issue you're experiencing with the HTTP node failing while the agent works correctly could be due to several factors. Here are some potential causes and solutions:

  1. AuthorizationConfigError: Ensure that the authorization configuration for the HTTP node is correct and valid. This error occurs when the authorization setup is missing or incorrect [1].

  2. FileFetchError: Check if there are any issues with fetching files that the HTTP node might be trying to access. This error is raised when a file cannot be fetched [1].

  3. InvalidHttpMethodError: Verify that the HTTP method used in the request is valid. An invalid HTTP method can cause this error [1].

  4. ResponseSizeError: Ensure that the response size does not exceed the allowed threshold. If it does, this error will be triggered [1].

  5. Retry Mechanism: The error message indicates that the maximum retries were reached. Dify uses a retry mechanism with exponential backoff for certain HTTP status codes (429, 500, 502, 503, 504). Check if the URL being accessed is returning one of these status codes, which would trigger retries [2].

  6. Squid Configuration: Double-check the squid.conf.template settings. Ensure that the ports and access rules are correctly configured to allow the HTTP node to connect to the agent's API. Specifically, verify that the Safe_ports and HTTP_ports configurations include the necessary ports, and that the http_access rules permit the required connections [3].

By addressing these potential issues, you should be able to resolve the HTTP node failure. If the problem persists, further investigation into the specific error messages and logs may be necessary to pinpoint the exact cause.

To continue talking to Dosu, mention @dosu.

@dosubot[bot] commented on GitHub (Dec 5, 2024): <!-- Answer --> The issue you're experiencing with the HTTP node failing while the agent works correctly could be due to several factors. Here are some potential causes and solutions: 1. **AuthorizationConfigError**: Ensure that the authorization configuration for the HTTP node is correct and valid. This error occurs when the authorization setup is missing or incorrect <sup>[[1]](https://github.com/langgenius/dify/blob/main/api/core/workflow/nodes/http_request/exc.py)</sup>. 2. **FileFetchError**: Check if there are any issues with fetching files that the HTTP node might be trying to access. This error is raised when a file cannot be fetched <sup>[[1]](https://github.com/langgenius/dify/blob/main/api/core/workflow/nodes/http_request/exc.py)</sup>. 3. **InvalidHttpMethodError**: Verify that the HTTP method used in the request is valid. An invalid HTTP method can cause this error <sup>[[1]](https://github.com/langgenius/dify/blob/main/api/core/workflow/nodes/http_request/exc.py)</sup>. 4. **ResponseSizeError**: Ensure that the response size does not exceed the allowed threshold. If it does, this error will be triggered <sup>[[1]](https://github.com/langgenius/dify/blob/main/api/core/workflow/nodes/http_request/exc.py)</sup>. 5. **Retry Mechanism**: The error message indicates that the maximum retries were reached. Dify uses a retry mechanism with exponential backoff for certain HTTP status codes (429, 500, 502, 503, 504). Check if the URL being accessed is returning one of these status codes, which would trigger retries <sup>[[2]](https://github.com/langgenius/dify/blob/main/api/core/helper/ssrf_proxy.py)</sup>. 6. **Squid Configuration**: Double-check the `squid.conf.template` settings. Ensure that the ports and access rules are correctly configured to allow the HTTP node to connect to the agent's API. Specifically, verify that the `Safe_ports` and `HTTP_ports` configurations include the necessary ports, and that the `http_access` rules permit the required connections <sup>[[3]](https://github.com/langgenius/dify/blob/main/docker/ssrf_proxy/squid.conf.template)</sup>. By addressing these potential issues, you should be able to resolve the HTTP node failure. If the problem persists, further investigation into the specific error messages and logs may be necessary to pinpoint the exact cause. <!-- Dosu Comment Footer --> *To continue talking to [Dosu](https://dosu.dev), mention @dosu.*
Author
Owner

@yuhp-zts commented on GitHub (Dec 5, 2024):

When I enter into docker-ssrf_proxy-1 and execute the following command, there is no issue.

curl -X POST 'http://10.26.xx.xx:8888/v1/chat-messages' \
--header 'Authorization: Bearer {api_key}' \
--header 'Content-Type: application/json' \
--data-raw '{
    "inputs": {},
    "query": "……",
    "response_mode": "streaming",
    "conversation_id": "",
    "user": "abc-123",
    "files": [
    ]
}'
@yuhp-zts commented on GitHub (Dec 5, 2024): When I enter into docker-ssrf_proxy-1 and execute the following command, there is no issue. ``` curl -X POST 'http://10.26.xx.xx:8888/v1/chat-messages' \ --header 'Authorization: Bearer {api_key}' \ --header 'Content-Type: application/json' \ --data-raw '{ "inputs": {}, "query": "……", "response_mode": "streaming", "conversation_id": "", "user": "abc-123", "files": [ ] }' ```
Author
Owner

@yuhp-zts commented on GitHub (Dec 5, 2024):

When more people call the app, the probability of this issue occurring increases. When fewer people call, it can occasionally execute the HTTP request successfully.

@yuhp-zts commented on GitHub (Dec 5, 2024): When more people call the app, the probability of this issue occurring increases. When fewer people call, it can occasionally execute the HTTP request successfully.
Author
Owner

@crazywoola commented on GitHub (Dec 5, 2024):

When more people call the app, the probability of this issue occurring increases. When fewer people call, it can occasionally execute the HTTP request successfully.

Then I guess it's not about the configuration itself. Maybe it's related to the concurrency. http://10.26.xx.xx:8888 This endpoint seems to be start from the source code?

@crazywoola commented on GitHub (Dec 5, 2024): > When more people call the app, the probability of this issue occurring increases. When fewer people call, it can occasionally execute the HTTP request successfully. Then I guess it's not about the configuration itself. Maybe it's related to the concurrency. `http://10.26.xx.xx:8888` This endpoint seems to be start from the source code?
Author
Owner

@chenyongqing commented on GitHub (Dec 5, 2024):

@crazywoola Hello, I've encountered the same issue in version 0.12.1 as well. Have you resolved it?

@chenyongqing commented on GitHub (Dec 5, 2024): @crazywoola Hello, I've encountered the same issue in version 0.12.1 as well. Have you resolved it?
Author
Owner

@yuhp-zts commented on GitHub (Dec 6, 2024):

@crazywoola Hello, I've encountered the same issue in version 0.12.1 as well. Have you resolved it?

SERVER_WORKER_AMOUNT,CELERY_WORKER_AMOUNT可以 调大一点

@yuhp-zts commented on GitHub (Dec 6, 2024): > @crazywoola Hello, I've encountered the same issue in version 0.12.1 as well. Have you resolved it? SERVER_WORKER_AMOUNT,CELERY_WORKER_AMOUNT可以 调大一点
Author
Owner

@chenyongqing commented on GitHub (Dec 6, 2024):

@crazywoola Hello, I've encountered the same issue in version 0.12.1 as well. Have you resolved it?

SERVER_WORKER_AMOUNT,CELERY_WORKER_AMOUNT可以 调大一点

Everything looks good after applying your suggestions. thx! @yuhp-zts

@chenyongqing commented on GitHub (Dec 6, 2024): > > @crazywoola Hello, I've encountered the same issue in version 0.12.1 as well. Have you resolved it? > > SERVER_WORKER_AMOUNT,CELERY_WORKER_AMOUNT可以 调大一点 Everything looks good after applying your suggestions. thx! @yuhp-zts
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#7070