Replies: 3 comments 5 replies
|
@yanpx169 — This is the same SSRF proxy issue you resolved in your previous discussions, but now it's hitting the internal The sandbox routes all HTTP requests through the Squid SSRF proxy, which blocks private/internal addresses by default since 1.15.0 [1]. Even though you switched from Fix: Add SSRF_PROXY_ALLOW_PRIVATE_DOMAINS=ibot.zx.xxx.com.cn,apiThen restart: docker compose down && docker compose up -dThis is the same mechanism you used to unblock Alternative approach: Instead of making raw HTTP requests from the code node to download files, consider using Dify's built-in file variable handling, which passes file content directly into the node without needing to call the internal API. This would avoid the SSRF proxy entirely and would be more resilient across upgrades. To reply, just mention @dosu. Share context across your team and agents. Try Dosu.
|
|
If this method already exists, could you please tell us how to use the built-in file variable function of Dify within the code node to obtain the content of the file? I will try this method. It is definitely more elegant Fix: Add api to the SSRF proxy allowlist in your .env file: But there are still errors: |
|
@yanpx169 The new error
Regarding your question about built-in file variable handling in code nodes — unfortunately, code nodes do not support file variables. This is an intentional design limitation [1]:
Recommended alternative workflow: Instead of making raw HTTP requests from the code node, restructure your workflow like this:
This separates file fetching (HTTP Request node) from file processing (Code node), avoids the proxy resolution issues entirely, and is more resilient across version upgrades. To reply, just mention @dosu. Share context across your team and agents. Try Dosu.
|
|
I made the modifications based on your suggestions, but it still prompted an abnormal connection
docker-compose.yaml volumes/sandbox/conf/config.yaml Recommended alternative workflow: |
|
@yanpx169 The DNS resolution error ( Fix the DNS issueSince you've commented out sandbox:
environment:
HTTP_PROXY: ""
HTTPS_PROXY: ""
http_proxy: ""
https_proxy: ""Also verify it's actually working by exec-ing into the sandbox: docker compose exec sandbox sh -c "nslookup api"If sandbox:
networks:
- defaultThen Better approach for your workflowYou're right that the HTTP Request node has size limits and the code node can't natively access file variables — this is by design [1]. But your actual goal is just to detect the file type by reading Excel headers, not to process the full 1GB file. Your current approach (HTTP request from code node to response = requests.get(full_url, timeout=30, headers={"Range": "bytes=0-65535"})This reads only the first 64KB, which is plenty for Excel header/column detection, regardless of whether the file is 1MB or 1GB. So the recommended path is: keep your current code node approach, just fix the networking issue above so the sandbox can reach To reply, just mention @dosu. Share context across your team and agents. Try Dosu.
|
|
Adding to the SSRF proxy explanation, here's what's happening at the code level: Dify's The issue is that your code node is running in the sandbox environment, which routes all HTTP requests through the Squid SSRF proxy. The proxy blocks private/internal addresses by default for security reasons. Two solutions: Solution 1: Allowlist the Solution 2: Use file variables directly (better approach) In your workflow:
This approach is more resilient because:
The |
|
How exactly do you pass file variables to the code node and directly read the file content? I tried to find that the information passed to the file variable was only the following, and I didn't see the specific content of the file 
|
|
To answer your specific follow-up: yes, Code nodes do support File-type Setup:
One gotcha: file content is only fetched into the sandbox on the first This sidesteps your entire SSRF proxy / |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Self Checks
1. Is this request related to a challenge you're experiencing? Tell me about your story.
When I upgraded from dify version 1.15.0 to version 1.16.0, Normal code doesn't work properly? How can it be solved?
I obtain the files uploaded by users through code nodes and determine the type of the files based on their content：
But the error prompt reads: "Request failed, status code: 403".
log:
my code:
All reactions