langgenius / langgenius/dify

Upstream 401 response is incorrectly classified as ToolSSRFError when passing through Squid

Open
#41,434 1 comment 1 reaction 0 assignees View on GitHub
🐞 bug
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.