langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-21 20:15:31 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

modify squid.conf.template then restart ssrf_proxy service but call local net api not work #15279

New Issue
Closed
opened 2026-02-21 19:21:00 -05:00 by yindo · 3 comments
yindo commented 2026-02-21 19:21:00 -05:00
Owner
Copy Link
Copy Source

Originally created by @itning on GitHub (Jul 11, 2025).

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

1.6.0

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

I have configured an HTTP tool in my custom tools, accessing the domain: http://nas.itning.cn:8895. I modified the squid.conf.template file as follows, but it only responds correctly the first time; on the second attempt, it returns a 404 error. How can I resolve this issue?

nas.itning.cn ip is 192.168.10.244

Image Image 

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 SSL_ports port 1025-65535   # Enable the configuration to resolve this issue: https://github.com/langgenius/dify/issues/12792
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 CONNECT method CONNECT
acl allowed_domains dstdomain .marketplace.dify.ai .itning.cn
http_access allow allowed_domains
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
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

# Unless the option's size is increased, an error will occur when uploading more than two files.
client_request_buffer_max_size 100 MB

I modify this line:
acl allowed_domains dstdomain .marketplace.dify.ai
to
acl allowed_domains dstdomain .marketplace.dify.ai .itning.cn

ssrf_proxy log:

2025/07/11 09:20:01 pinger| Initialising ICMP pinger ...
2025/07/11 09:20:01 pinger| ICMP socket opened.
2025/07/11 09:20:01 pinger| ICMPv6 socket opened
2025/07/11 09:20:02| storeLateRelease: released 0 objects
2025/07/11 09:20:08| temporary disabling (Not Found) digest from sandbox
1752225608.355      1 172.20.0.8 TCP_MISS/404 231 GET http://nas.itning.cn:8895/since_yesterday_11pm - FIRSTUP_PARENT/172.21.0.2 text/plain
1752225612.299   3076 172.20.0.8 TCP_MISS/200 9990 GET http://nas.itning.cn:8895/since_yesterday_11pm - HIER_DIRECT/198.18.0.35 application/json
1752225695.236      0 172.20.0.8 TCP_REFRESH_MODIFIED/404 238 GET http://nas.itning.cn:8895/since_yesterday_11pm - FIRSTUP_PARENT/172.21.0.2 text/plain
1752225696.296      0 172.20.0.8 TCP_MISS/404 228 GET http://nas.itning.cn:8895/since_yesterday_11pm - FIRSTUP_PARENT/172.21.0.2 text/plain
1752225769.598      1 172.20.0.8 TCP_MISS/404 228 GET http://nas.itning.cn:8895/since_yesterday_11pm - FIRSTUP_PARENT/172.21.0.2 text/plain
1752225875.199      1 172.20.0.8 TCP_MISS/404 228 GET http://nas.itning.cn:8895/since_yesterday_11pm - FIRSTUP_PARENT/172.21.0.2 text/plain
2025/07/11 09:25:08| temporary disabling (Not Found) digest from sandbox

✔️ Expected Behavior

call success

❌ Actual Behavior

call failed, return 404

Originally created by @itning on GitHub (Jul 11, 2025). ### 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 1.6.0 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce I have configured an HTTP tool in my custom tools, accessing the domain: http://nas.itning.cn:8895. I modified the squid.conf.template file as follows, but it only responds correctly the first time; on the second attempt, it returns a 404 error. How can I resolve this issue? nas.itning.cn ip is 192.168.10.244 <img width="1316" height="1422" alt="Image" src="https://github.com/user-attachments/assets/67f95e86-336f-46b6-aa63-d9214f5a2190" /> <img width="1220" height="798" alt="Image" src="https://github.com/user-attachments/assets/a79f82c4-5890-4a1c-a7eb-7b3d22cafbd9" /> ```shell 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 SSL_ports port 1025-65535 # Enable the configuration to resolve this issue: https://github.com/langgenius/dify/issues/12792 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 CONNECT method CONNECT acl allowed_domains dstdomain .marketplace.dify.ai .itning.cn http_access allow allowed_domains http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow localhost manager 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 # Unless the option's size is increased, an error will occur when uploading more than two files. client_request_buffer_max_size 100 MB ``` I modify this line: acl allowed_domains dstdomain .marketplace.dify.ai to acl allowed_domains dstdomain .marketplace.dify.ai .itning.cn ssrf_proxy log: ``` 2025/07/11 09:20:01 pinger| Initialising ICMP pinger ... 2025/07/11 09:20:01 pinger| ICMP socket opened. 2025/07/11 09:20:01 pinger| ICMPv6 socket opened 2025/07/11 09:20:02| storeLateRelease: released 0 objects 2025/07/11 09:20:08| temporary disabling (Not Found) digest from sandbox 1752225608.355 1 172.20.0.8 TCP_MISS/404 231 GET http://nas.itning.cn:8895/since_yesterday_11pm - FIRSTUP_PARENT/172.21.0.2 text/plain 1752225612.299 3076 172.20.0.8 TCP_MISS/200 9990 GET http://nas.itning.cn:8895/since_yesterday_11pm - HIER_DIRECT/198.18.0.35 application/json 1752225695.236 0 172.20.0.8 TCP_REFRESH_MODIFIED/404 238 GET http://nas.itning.cn:8895/since_yesterday_11pm - FIRSTUP_PARENT/172.21.0.2 text/plain 1752225696.296 0 172.20.0.8 TCP_MISS/404 228 GET http://nas.itning.cn:8895/since_yesterday_11pm - FIRSTUP_PARENT/172.21.0.2 text/plain 1752225769.598 1 172.20.0.8 TCP_MISS/404 228 GET http://nas.itning.cn:8895/since_yesterday_11pm - FIRSTUP_PARENT/172.21.0.2 text/plain 1752225875.199 1 172.20.0.8 TCP_MISS/404 228 GET http://nas.itning.cn:8895/since_yesterday_11pm - FIRSTUP_PARENT/172.21.0.2 text/plain 2025/07/11 09:25:08| temporary disabling (Not Found) digest from sandbox ``` ### ✔️ Expected Behavior call success ### ❌ Actual Behavior call failed, return 404
yindo added the 🤔 cant-reproducestale labels 2026-02-21 19:21:00 -05:00
yindo closed this issue 2026-02-21 19:21:00 -05:00
yindo commented 2026-02-21 19:21:00 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Jul 11, 2025):

To make sure your changes to squid.conf.template are applied, you need to fully stop and remove the ssrf_proxy container, then start it again (not just restart the service). This is because the entrypoint script that processes the template and generates the actual squid.conf only runs on a full container start, not on a simple restart. Use docker-compose down and then docker-compose up -d for the ssrf_proxy service to ensure your config changes take effect cite.

If you still get 404 errors after this, check if Squid's caching is interfering. You can try disabling caching for your endpoint by adding a line like cache deny all or adjusting the refresh_pattern for your specific path in the config. Also, check the logs on your target server (nas.itning.cn:8895) to see if it is returning 404s after the first request, which could indicate a server-side issue.

Finally, make sure the Docker network allows the ssrf_proxy container to reach 192.168.10.244. If the problem persists, it may be related to Squid's internal caching or digest logic, which isn't managed by Dify itself cite.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Join Discord Share on X

@dosubot[bot] commented on GitHub (Jul 11, 2025): <!-- Answer --> To make sure your changes to squid.conf.template are applied, you need to fully stop and remove the ssrf_proxy container, then start it again (not just restart the service). This is because the entrypoint script that processes the template and generates the actual squid.conf only runs on a full container start, not on a simple restart. Use `docker-compose down` and then `docker-compose up -d` for the ssrf_proxy service to ensure your config changes take effect [cite](https://github.com/langgenius/dify/blob/1d85979a7464d8d4d01e582eb6083d4206ea46ba/docker/ssrf_proxy/docker-entrypoint.sh). If you still get 404 errors after this, check if Squid's caching is interfering. You can try disabling caching for your endpoint by adding a line like `cache deny all` or adjusting the `refresh_pattern` for your specific path in the config. Also, check the logs on your target server (nas.itning.cn:8895) to see if it is returning 404s after the first request, which could indicate a server-side issue. Finally, make sure the Docker network allows the ssrf_proxy container to reach 192.168.10.244. If the problem persists, it may be related to Squid's internal caching or digest logic, which isn't managed by Dify itself [cite](https://github.com/crazywoola/dify-docs-mintlify/blob/ef2d56c19222d395f51c076e3d934af9c143b841/en/learn-more/faq/install-faq.mdx). <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/d4fcf4c0-4eab-404f-9ae4-dce18b29aeb5?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/d4fcf4c0-4eab-404f-9ae4-dce18b29aeb5?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/d4fcf4c0-4eab-404f-9ae4-dce18b29aeb5?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/d4fcf4c0-4eab-404f-9ae4-dce18b29aeb5?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/d4fcf4c0-4eab-404f-9ae4-dce18b29aeb5?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/d4fcf4c0-4eab-404f-9ae4-dce18b29aeb5?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/d4fcf4c0-4eab-404f-9ae4-dce18b29aeb5?feedback_type=other)</sup>&nbsp;&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/22228)
yindo commented 2026-02-21 19:21:00 -05:00
Author
Owner
Copy Link
Copy Source

@itning commented on GitHub (Jul 11, 2025):

when I execute this command:

docker compose restart ssrf_proxy

and then test:

Image

but second time is:

Image
@itning commented on GitHub (Jul 11, 2025): when I execute this command: `docker compose restart ssrf_proxy` and then test: <img width="1228" height="1044" alt="Image" src="https://github.com/user-attachments/assets/7b3ffab1-07b4-4259-8b36-6f72d16b9bc5" /> but second time is: <img width="1258" height="820" alt="Image" src="https://github.com/user-attachments/assets/dfa82dcd-84bf-4a92-883c-6fa3e8e0586f" />
yindo commented 2026-02-21 19:21:00 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Aug 28, 2025):

Hi, @itning. I'm Dosu, and I'm helping the Dify team manage their backlog and am marking this issue as stale.

Issue Summary

  • You reported a 404 error on the second request when accessing a local API via a modified squid.conf.template in a self-hosted Dify 1.6.0 Docker setup.
  • The first request succeeds, but subsequent requests fail with a 404.
  • I suggested fully stopping and removing the ssrf_proxy container before restarting to apply config changes, as a simple restart may not reprocess the template.
  • You tried restarting the container with docker compose restart ssrf_proxy but the 404 error on the second request persists.
  • No resolution or further updates have been provided since.

Next Steps

  • Please confirm if this issue is still relevant with the latest version of Dify and if you can reproduce it.
  • If it remains an issue, feel free to comment here to keep the discussion open; otherwise, this issue will be automatically closed in 15 days.

Thank you for your understanding and contribution!

@dosubot[bot] commented on GitHub (Aug 28, 2025): Hi, @itning. I'm [Dosu](https://dosu.dev), and I'm helping the Dify team manage their backlog and am marking this issue as stale. **Issue Summary** - You reported a 404 error on the second request when accessing a local API via a modified squid.conf.template in a self-hosted Dify 1.6.0 Docker setup. - The first request succeeds, but subsequent requests fail with a 404. - I suggested fully stopping and removing the ssrf_proxy container before restarting to apply config changes, as a simple restart may not reprocess the template. - You tried restarting the container with `docker compose restart ssrf_proxy` but the 404 error on the second request persists. - No resolution or further updates have been provided since. **Next Steps** - Please confirm if this issue is still relevant with the latest version of Dify and if you can reproduce it. - If it remains an issue, feel free to comment here to keep the discussion open; otherwise, this issue will be automatically closed in 15 days. Thank you for your understanding and contribution!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label stale 🤔 cant-reproduce
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#15279
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?