Discussion on issues related to intelligent agents

[biayuan]

Self Checks

• 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.

Content

Why does an interface query tool I wrote run fine when run alone, but gets rejected when I put it into an agent and ask the agent to call it?

[dosubot[bot]]

Hi @biayuan! I'm Dosu and I’m helping the dify team.

There are several reasons why a tool might work standalone but get rejected when called by an agent in Dify:

• If your tool or plugin expects an attribute like agent.model, but the agent runner class only exposes agent.model_instance.model, this mismatch will cause rejection. Update your tool to reference agent.model_instance.model instead, or add a property to the agent runner class to expose the expected attribute. This is a common cause of agent-tool interface errors in Dify (details).

• Agent calls can fail due to JSON serialization issues. If your tool's input/output isn't strictly valid JSON, the agent may reject it. Recent updates improved error handling by switching from JSONDecodeError to TypeError and adding fallback encoding, but you should still ensure your tool's messages are properly formatted (details).

• If the agent can't reach your local AI service (as shown by the connection refused error in your screenshot), check that the service is running and accessible from the agent's environment.

• Some models (like Qwen) or plugins may behave inconsistently with agent function calls, or the agent may ignore tools based on the model's decision-making pattern. Trying a different model can sometimes resolve this (details).

• If your tool streams large files or data, Dify now uses a unified chunk merging utility for agents and tools. Make sure your tool respects the file (30MB) and chunk (8KB) size limits, or it will be rejected (details).

If you share the exact error message or logs from the agent run, I can help pinpoint the issue more precisely.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[biayuan]

I made a tool myself. The tool does not require parameters for get requests when making HTTP requests. There is output when running it alone, but when I put it in the intelligent agent, it shows that the address is rejected. Is it related to the security policy of Dify? @dosu

[dosubot[bot]]

Yes, this is likely related to Dify's security and network policies. When your tool runs standalone, it uses your local environment's network, but when called by an agent, Dify routes all HTTP requests through its SSRF (Server-Side Request Forgery) protection layer. There is no configuration option in Dify to explicitly whitelist or allow local/private addresses for agent tools. If SSRF proxy settings are enabled or your agent runs in a different network environment (like a container), requests to local addresses (such as 127.0.0.1 or private IPs) may be blocked or unreachable by design to prevent security risks (source).

To work around this, make sure your service is accessible from the agent's network context—this might mean exposing your local service to the network where the agent runs, or using a proxy that the agent can reach. There is no in-app whitelist or environment variable to permit local addresses for agent tools (source). If you need to access local resources, you’ll need to adjust your network or proxy setup accordingly.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[biayuan]

So where can I set up a proxy to allow the agent to access the server?@dosu

[biayuan]

@dosu

[dosubot[bot]]

To let a Dify agent access your server, you need to adjust the SSRF proxy (Squid) settings and Docker environment:

1. Edit the Squid ACLs: In your Dify deployment, open docker/ssrf_proxy/squid.conf.template. Add an ACL rule to allow your server’s IP or domain before any http_access deny all line, for example:

   acl allowed_local dstdomain 10.5.132.73
   http_access allow allowed_local
   

   Then restart the ssrf_proxy container so the changes take effect. You can check if requests are allowed or denied by running docker logs <ssrf_proxy_container> while testing requests from the agent. Reference

2. Set proxy environment variables: In your .env file and Docker Compose, set SSRF_PROXY_HTTP_URL and SSRF_PROXY_HTTPS_URL to your proxy’s address. Also, set HTTP_PROXY and HTTPS_PROXY for the plugin_daemon service. Example:

   SSRF_PROXY_HTTP_URL=http://your-proxy:3128
   SSRF_PROXY_HTTPS_URL=http://your-proxy:3128
   

   In docker-compose.yml:

   environment:
     HTTP_PROXY: ${SSRF_PROXY_HTTP_URL}
     HTTPS_PROXY: ${SSRF_PROXY_HTTPS_URL}

   After changing these, restart the whole stack with docker-compose down and docker-compose up -d. Reference

3. Make sure your local service is reachable from the Dify agent’s network. If Dify runs in Docker, expose your service on the host or bridge network, or use a reverse proxy/public IP.

4. For debugging, exec into the Dify container and use curl to test connectivity to your server. Check Squid logs for denied requests if you run into issues.

By default, Dify’s SSRF proxy blocks all private/internal networks unless explicitly allowed in the ACLs, so you must whitelist your server’s address for agent access. This setup helps prevent SSRF attacks and keeps your deployment secure. Reference

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[biayuan]

I have configured it but the agent node still reports an error.@dosu

[biayuan]

The agent plug-in has been denied access.

[biayuan]

It's a problem with my plugin container configuration