Upstream 401 response is incorrectly classified as ToolSSRFError when passing through Squid
- Dominant language
- TypeScript
- Stars
- 156k
- Forks
- 24.6k
- Avg merge
- 22h 9m
- Merged PRs (30d)
- 610
Description
### Self Checks
- [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542).
- [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, otherwise it will be closed.
- [x] 【中文用户 & Non English User】请使用英语提交,否则会被关闭 :)
- [x] Please do not modify this template :) and fill in all the required fields.
### Dify version
1.16.0
### Cloud or Self Hosted
Self Hosted (Docker)
### Steps to reproduce
The target service itself returns:
HTTP/1.1 401 Unauthorized
Server: nginx
When the same request passes through Dify's Squid SSRF proxy, the response becomes:
HTTP/1.1 401 Unauthorized
Server: nginx
Via: 1.1 xxxx (squid/6.13)
The Squid access log shows:
TCP_MISS/401
which indicates that Squid successfully forwarded the request to the upstream server and received a 401 response, rather than blocking it with an ACL rule.
However, Dify still raises ToolSSRFError.
### ✔️ Expected Behavior
If the upstream server returns 401 or 403 and Squid only forwards that response, Dify should preserve the original upstream status instead of raising ToolSSRFError.
For example:
Server: nginx
Via: ... squid
should not by itself be considered sufficient evidence that the response was generated by the SSRF proxy.
Only responses actually generated by Squid due to SSRF ACL rejection should be converted into ToolSSRFError.
### ❌ Actual Behavior
HTTP node failed and output "Access to '{url}' was blocked by SSRF protection. The URL may point to a pricate or local network address."
Contributor guide
Research direction
Start at the HTTP node's SSRF response-classification path and inspect how responses forwarded by Squid are distinguished from responses generated by its ACL rejection. Reproduce the 401 case through the Squid SSRF proxy, then verify that forwarded upstream 401/403 responses retain their status while genuine SSRF blocks still produce ToolSSRFError.
Written by the indexing model from the issue text.
Assessment
- Domain
- backend, networking, security
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 50/100