dify Knowledge Base Q&A Image Output Conflicts with Mineru Plugin Configuration

Self Checks

[x] I have read the Contributing Guide and Language Policy.
[x] This is only for bug report, if you would like to ask a question, please head to Discussions.
[x] I have searched for existing issues search for existing 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

v1.11.1

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

I have locally deployed Dify v1.11.1 on a MacBook M4 via Docker, where Docker runs on Docker Desktop installed on the Mac. Initially, I set FILES_URL=http://local:5001 in the .env file—this is the only way to display images parsed from documents in the Knowledge Base Q&A output. For example, images extracted from Word documents appear as . This configuration is based on the solution provided in your GitHub issue: https://github.com/langgenius/dify/issues/29090

However, when FILES_URL is set to http://local:5001, the Mineru plugin (version: v0.5.1) fails to work properly and throws the following error: "An error occurred in the langgenius/mineru/mineru, please contact the author of langgenius/mineru/mineru for help, error type: ConnectError, error details: [Errno 111] Connection refused"

The Mineru plugin only functions correctly if FILES_URL is set to http://api:5001. Therefore, I am confused—aren't the configurations for these two features conflicting? Could you please provide a solution to make both the Knowledge Base Q&A image display and the Mineru plugin work properly simultaneously? thanks!

env.txt

docker-compose.yaml

✔️ Expected Behavior

none

❌ Actual Behavior

none

Dec 21 '25 13:12 comaaxl

This conflict happens because FILES_URL is used for external file access (like image display in your browser), while plugins such as Mineru need to access files via the internal Docker network address. Dify supports a separate INTERNAL_FILES_URL environment variable for this purpose.

To resolve both issues, set your environment variables as follows:

FILES_URL to the externally-accessible address (e.g., http://local:5001) so images display correctly in the Knowledge Base Q&A.
INTERNAL_FILES_URL to the internal Docker network address (e.g., http://api:5001) so Mineru can connect without errors.

Both variables should be set in your .env and referenced in your docker-compose.yaml. After updating, restart all relevant containers to apply the changes.

This setup works because Dify's codebase prioritizes INTERNAL_FILES_URL for internal plugin/service communication and FILES_URL for browser access, allowing both features to function simultaneously (feature config, file helpers, docker-compose.yaml).

To reply, just mention @dosu.

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

Dec 21 '25 13:12 dosubot[bot]

@dosu @dosu

But strangely enough, I currently have the following settings in my .env file: FILES_URL=http://localhost:5001 INTERNAL_FILES_URL=http://api:5001

Additionally, the following variables are defined at the very top of my docker_compose.yaml file:

FILES_URL: ${FILES_URL:-} INTERNAL_FILES_URL: ${INTERNAL_FILES_URL:-}

However, in practice, while the images in the Knowledge Base Q&A can be displayed normally, the Mineru plugin still throws an error：

The Mineru plugin only works properly if I set FILES_URL=http://api:5001. But in this case, when conducting Q&A, the images flash briefly (i.e., the original Markdown format of the images appears for a split second and then disappears immediately) and fail to be displayed persistently.

It seems that the configuration you suggested does not resolve the issue as expected. Additionally, regarding your recommendation to reference FILES_URL and INTERNAL_FILES_URL in docker_compose.yaml, do I need to add these references specifically within the api service configuration? I have provided my two configuration files below. Could you please help analyze and resolve this problem? Thank you!

env.txt

docker-compose.yaml

Dec 21 '25 14:12 comaaxl

@dosu api log:

2025-12-21 14:11:16.321 INFO [Dummy-9] [_client.py:1038] - HTTP Request: GET http://plugin_daemon:5002/plugin/e0bceaf9-2ab5-45db-85da-e9da7d368333/management/triggers?page=1&page_size=256⁠ "HTTP/1.1 200 OK"

2025-12-21 14:11:16.323 INFO [Dummy-5] [_client.py:1038] - HTTP Request: GET http://plugin_daemon:5002/plugin/e0bceaf9-2ab5-45db-85da-e9da7d368333/management/models?page=1&page_size=256⁠ "HTTP/1.1 200 OK"

2025-12-21 14:11:16.330 INFO [Dummy-8] [_client.py:1038] - HTTP Request: GET http://plugin_daemon:5002/plugin/e0bceaf9-2ab5-45db-85da-e9da7d368333/management/models?page=1&page_size=256⁠ "HTTP/1.1 200 OK"

2025-12-21 14:11:19.698 INFO [Dummy-46] [_client.py:1038] - HTTP Request: GET http://plugin_daemon:5002/plugin/e0bceaf9-2ab5-45db-85da-e9da7d368333/management/tool?provider=mineru&plugin_id=langgenius%2Fmineru⁠ "HTTP/1.1 200 OK"

2025-12-21 14:11:19.818 INFO [GraphWorker-0] [_client.py:1038] - HTTP Request: GET http://plugin_daemon:5002/plugin/e0bceaf9-2ab5-45db-85da-e9da7d368333/management/tool?provider=mineru&plugin_id=langgenius%2Fmineru⁠ "HTTP/1.1 200 OK"

2025-12-21 14:11:20.058 INFO [GraphWorker-0] [_client.py:1038] - HTTP Request: POST http://plugin_daemon:5002/plugin/e0bceaf9-2ab5-45db-85da-e9da7d368333/dispatch/tool/invoke⁠ "HTTP/1.1 200 OK"

2025-12-21 14:11:20.060 ERROR [GraphWorker-0] [base.py:277] - Error in stream response for plugin {'code': -500, 'message': '{"message":"{\"args\":{},\"error_type\":\"ConnectError\",\"message\":\"[Errno 111] Connection refused\"}","error_type":"PluginInvokeError","args":null}', 'data': None}

2025-12-21 14:11:20.060 ERROR [GraphDispatcher] [error_handler.py:101] - Node 1766320785291 failed with ABORT strategy: An error occurred in the langgenius/mineru/mineru, please contact the author of langgenius/mineru/mineru for help, error type: ConnectError, error details: [Errno 111] Connection refused

2025-12-21 14:11:20.162 ERROR [Thread-17 (_generate_worker)] [workflow_entry.py:111] - Unknown Error when workflow entry running

Traceback (most recent call last):

File "/app/api/core/workflow/workflow_entry.py", line 107, in run

yield from generator

File "/app/api/core/workflow/graph_engine/graph_engine.py", line 270, in run

raise self._graph_execution.error

RuntimeError: An error occurred in the langgenius/mineru/mineru, please contact the author of langgenius/mineru/mineru for help, error type: ConnectError, error details: [Errno 111] Connection refused

2025-12-21 14:11:21.270 INFO [Dummy-15] [_client.py:1038] - HTTP Request: GET http://plugin_daemon:5002/plugin/e0bceaf9-2ab5-45db-85da-e9da7d368333/management/tool?provider=mineru&plugin_id=langgenius%2Fmineru⁠ "HTTP/1.1 200 OK"

plugin_daemon log:

[GIN] 2025/12/21 - 14:11:16 | 200 | 890.625µs | 172.20.0.11 | GET "/plugin/e0bceaf9-2ab5-45db-85da-e9da7d368333/management/triggers?page=1&page_size=256"

[GIN] 2025/12/21 - 14:11:16 | 200 | 2.990541ms | 172.20.0.11 | GET "/plugin/e0bceaf9-2ab5-45db-85da-e9da7d368333/management/models?page=1&page_size=256"

[GIN] 2025/12/21 - 14:11:16 | 200 | 12.223625ms | 172.20.0.11 | GET "/plugin/e0bceaf9-2ab5-45db-85da-e9da7d368333/management/models?page=1&page_size=256"

[GIN] 2025/12/21 - 14:11:19 | 200 | 699.542µs | 172.20.0.11 | GET "/plugin/e0bceaf9-2ab5-45db-85da-e9da7d368333/management/tool?provider=mineru&plugin_id=langgenius%2Fmineru"

[GIN] 2025/12/21 - 14:11:19 | 200 | 588.083µs | 172.20.0.11 | GET "/plugin/e0bceaf9-2ab5-45db-85da-e9da7d368333/management/tool?provider=mineru&plugin_id=langgenius%2Fmineru"

[GIN] 2025/12/21 - 14:11:20 | 200 | 216.448166ms | 172.20.0.11 | POST "/plugin/e0bceaf9-2ab5-45db-85da-e9da7d368333/dispatch/tool/invoke"

[GIN] 2025/12/21 - 14:11:21 | 200 | 522.5µs | 172.20.0.11 | GET "/plugin/e0bceaf9-2ab5-45db-85da-e9da7d368333/management/tool?provider=mineru&plugin_id=langgenius%2Fmineru"

[GIN] 2025/12/21 - 14:11:40 | 200 | 772.375µs | 172.20.0.11 | GET "/plugin/e0bceaf9-2ab5-45db-85da-e9da7d368333/management/tool?provider=mineru&plugin_id=langgenius%2Fmineru"

Dec 21 '25 14:12 comaaxl

Your current setup is running into this issue because Docker containers can't access your host's localhost, and INTERNAL_FILES_URL takes priority for plugin access. Here’s how to resolve it:

In your .env file, set FILES_URL to your host's LAN IP (for example, http://192.168.x.x:5001), not localhost or api. Leave INTERNAL_FILES_URL blank.
In your docker-compose.yaml, under the api service, add a ports mapping:
```
ports:
  - "5001:5001"
```
This exposes the file server to your host/LAN.
Restart all containers with docker-compose down && docker-compose up -d to apply changes.
Verify the environment variables inside both the api and plugin_daemon containers using docker exec <container> env to ensure the correct values are loaded.
Test file server accessibility from your browser (using the LAN IP and port 5001) and from within the plugin_daemon container (using curl or wget to the FILES_URL address).

This setup ensures that images display in the Knowledge Base Q&A and the Mineru plugin can connect without errors. If you still see issues, double-check your Docker port mapping and that the correct .env file is being used. More details and examples are available in the docs and related issues (source, source).

To reply, just mention @dosu.

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

Dec 21 '25 14:12 dosubot[bot]

@dosu @dosu FILES_URL=http://192.168.0.110:5001 INTERNAL_FILES_URL=

the environment variables inside both the api and plugin_daemon containers using docker exec env to ensure the correct values are loaded.

now the Mineru plugin throws an error：

api log

RuntimeError: An error occurred in the langgenius/mineru/mineru, please contact the author of langgenius/mineru/mineru for help, error type: Exception, error details: Failed to create parsing task: HTTPSConnectionPool(host='mineru.net', port=443): Max retries exceeded with url: /api/v4/file-urls/batch (Caused by NameResolutionError("HTTPSConnection(host='mineru.net', port=443): Failed to resolve 'mineru.net' ([Errno -3] Temporary failure in name resolution)"))

2025-12-21 14:39:41.088 INFO [Dummy-6] [_client.py:1038] - HTTP Request: GET http://plugin_daemon:5002/plugin/e0bceaf9-2ab5-45db-85da-e9da7d368333/management/tool?provider=mineru&plugin_id=langgenius%2Fmineru⁠ "HTTP/1.1 200 OK"

2025-12-21 14:39:50.417 INFO [Dummy-5] [_client.py:1038] - HTTP Request: GET http://plugin_daemon:5002/plugin/e0bceaf9-2ab5-45db-85da-e9da7d368333/management/triggers?page=1&page_size=256⁠ "HTTP/1.1 200 OK"

2025-12-21 14:39:53.870 INFO [Dummy-4] [_client.py:1038] - HTTP Request: GET http://plugin_daemon:5002/plugin/e0bceaf9-2ab5-45db-85da-e9da7d368333/management/tool?provider=mineru&plugin_id=langgenius%2Fmineru⁠ "HTTP/1.1 200 OK"

2025-12-21 14:39:53.995 INFO [GraphWorker-0] [_client.py:1038] - HTTP Request: GET http://plugin_daemon:5002/plugin/e0bceaf9-2ab5-45db-85da-e9da7d368333/management/tool?provider=mineru&plugin_id=langgenius%2Fmineru⁠ "HTTP/1.1 200 OK"

2025-12-21 14:40:02.034 INFO [GraphWorker-0] [_client.py:1038] - HTTP Request: POST http://plugin_daemon:5002/plugin/e0bceaf9-2ab5-45db-85da-e9da7d368333/dispatch/tool/invoke⁠ "HTTP/1.1 200 OK"

2025-12-21 14:40:02.036 ERROR [GraphWorker-0] [base.py:277] - Error in stream response for plugin {'code': -500, 'message': '{"message":"{\"args\":{},\"error_type\":\"Exception\",\"message\":\"Failed to create parsing task: HTTPSConnectionPool(host='mineru.net', port=443): Max retries exceeded with url: /api/v4/file-urls/batch (Caused by NameResolutionError(\\\"HTTPSConnection(host='mineru.net', port=443): Failed to resolve 'mineru.net' ([Errno -3] Temporary failure in name resolution)\\\"))\"}","error_type":"PluginInvokeError","args":null}', 'data': None}

2025-12-21 14:40:02.125 ERROR [GraphDispatcher] [error_handler.py:101] - Node 1766320785291 failed with ABORT strategy: An error occurred in the langgenius/mineru/mineru, please contact the author of langgenius/mineru/mineru for help, error type: Exception, error details: Failed to create parsing task: HTTPSConnectionPool(host='mineru.net', port=443): Max retries exceeded with url: /api/v4/file-urls/batch (Caused by NameResolutionError("HTTPSConnection(host='mineru.net', port=443): Failed to resolve 'mineru.net' ([Errno -3] Temporary failure in name resolution)"))

2025-12-21 14:40:02.240 ERROR [Thread-7 (_generate_worker)] [workflow_entry.py:111] - Unknown Error when workflow entry running

Traceback (most recent call last):

File "/app/api/core/workflow/workflow_entry.py", line 107, in run

yield from generator

File "/app/api/core/workflow/graph_engine/graph_engine.py", line 270, in run

raise self._graph_execution.error

RuntimeError: An error occurred in the langgenius/mineru/mineru, please contact the author of langgenius/mineru/mineru for help, error type: Exception, error details: Failed to create parsing task: HTTPSConnectionPool(host='mineru.net', port=443): Max retries exceeded with url: /api/v4/file-urls/batch (Caused by NameResolutionError("HTTPSConnection(host='mineru.net', port=443): Failed to resolve 'mineru.net' ([Errno -3] Temporary failure in name resolution)"))

2025-12-21 14:40:05.033 INFO [Dummy-7] [_client.py:1038] - HTTP Request: GET http://plugin_daemon:5002/plugin/e0bceaf9-2ab5-45db-85da-e9da7d368333/management/tool?provider=mineru&plugin_id=langgenius%2Fmineru⁠ "HTTP/1.1 200 OK"

Dec 21 '25 14:12 comaaxl

The DNS error for mineru.net is caused by the SSRF proxy (ssrf_proxy service) in your Docker setup, which only allows outbound connections to domains listed in its ACL. By default, only .marketplace.dify.ai is allowed, so mineru.net is blocked.

To fix this, edit docker/ssrf_proxy/squid.conf.template and add mineru.net to the allowed_domains ACL, like this:

acl allowed_domains dstdomain .marketplace.dify.ai mineru.net
http_access allow allowed_domains
http_access deny all

Then, rebuild and restart the ssrf_proxy and plugin_daemon containers (docker-compose down && docker-compose up -d) to apply the change. This will allow the Mineru plugin to connect to mineru.net while keeping your current FILES_URL setup for image display in the Knowledge Base Q&A.
Reference

To reply, just mention @dosu.

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

Dec 21 '25 14:12 dosubot[bot]

@dosu @dosu

I haven't modified the configuration file "docker/ssrf_proxy/squid.conf.template".

After connecting to the "company's Wi-Fi"(10.21.176.242), I used the command "ipconfig getifaddr en0" to obtain the IP address, then set it in FILES_URL as http://[company's Wi-Fi IP]:5001, and left INTERNAL_FILES_URL empty. In this case, Dify can both use the Mineru plugin normally and display images in Knowledge Base Q&A.

However, after connecting to a "mobile hotspot"(172.20.10.2), I used the same command "ipconfig getifaddr en0" to get the IP address, then set it in FILES_URL as http://[mobile hotspot IP]:5001. After that, Mineru throws the following error:

now I have two questions to consult: 1.Why does Mineru fail to work properly when the IP address in FILES_URL is replaced with the one from the mobile hotspot? 2.If I use the company Wi-Fi's IP address in FILES_URL, I have to manually modify the IP in the .env file when the IP changes. This is quite cumbersome—are there any better solutions?

Additionally, I'd like to add that a colleague of mine deployed Dify in the same way on a "Tencent Cloud server". He only needs to set FILES_URL=http://api:5001, and both the Mineru plugin and the image display function work normally. Could this bug of mine be caused by deploying locally on a Mac instead of on a cloud server?

Dec 22 '25 01:12 comaaxl

When you switch to a mobile hotspot and set FILES_URL to your new IP, Docker containers on Mac often can't reach the host at that IP due to how Docker Desktop for Mac handles networking. This results in the "No route to host" error for Mineru—your containers can't access the host's file server via the hotspot IP, even though it works on your company Wi-Fi. This is a known limitation of Docker networking on Mac, especially with changing network interfaces and IPs.
You don't need to manually update FILES_URL every time your IP changes. On Mac (and Windows), Docker provides a special DNS name: host.docker.internal. Set both FILES_URL and INTERNAL_FILES_URL to http://host.docker.internal:5001 in your .env file. This alias always points to your host machine from inside containers, regardless of your current network or IP. Make sure port 5001 is published in your docker-compose.yaml under the api service:
```
ports:
  - "5001:5001"
```
Then restart your containers (docker-compose down && docker-compose up -d). This setup works for both browser image display and plugin access, and you won't need to update your IP again when switching networks.
Reference | Reference

Cloud servers (like Tencent Cloud) work with http://api:5001 because all services run inside Docker on a VM with a static internal network, so api:5001 is always reachable from both plugins and the frontend. On your Mac, the host's IP can change and isn't always reachable from containers, so host.docker.internal is the best solution.

If you need Mineru to access external domains (like mineru.net) and run into DNS errors, make sure to whitelist those domains in your SSRF proxy config as discussed earlier, but that's separate from the host IP issue.

Let me know if you need a concrete example .env or docker-compose.yaml snippet!

To reply, just mention @dosu.

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

Dec 22 '25 01:12 dosubot[bot]

@dosu @dosu

My current settings are as follows: FILES_URL=http://host.docker.internal:5001/ INTERNAL_FILES_URL=

This configuration has resolved the document parsing issue with the Mineru plugin.

However, a new problem has emerged with another plugin. I am using the "Knowledge Pro" plugin and attempting to insert the results parsed by Mineru into the knowledge base, but the following error occurs:

Failed to create document: One or more files not found.

I have tried changing FILES_URL to http://api:5001 and INTERNAL_FILES_URL to http://api:5001 as well, but neither works. The service API of the knowledge base (where I intend to insert the parsed results) is shown in the image below:

(Do I need to modify the localhost part in the API endpoint http://localhost/v1 of this service API? I have no idea where I can make this change.)

I can see that the API endpoint is displayed as http://localhost/v1. Currently, in the configuration of the "Knowledge Pro" plugin, I have set it to http://[my IP address]/v1. Even if I modify it to http://host.docker.internal/v1, it still fails to work. If I directly replace it with http://localhost/v1, another error occurs as shown in the following image:

By the way, I have deployed Dify locally on my MacBook via Docker Desktop, and I have also added the following entries to the /etc/hosts file: 127.0.0.1 host.docker.internal localhost host.docker.internal

Additionally, a colleague of mine has the exact same Dify configuration as mine, except that he deployed it on a Tencent Cloud server, and his "Knowledge Pro" plugin works properly without any issues.

Please help me analyze the root cause of this problem and provide a solution. Thank you!

env.txt

docker-compose.yaml

Dec 23 '25 13:12 comaaxl

The "One or more files not found" error in the Knowledge Pro plugin is almost always caused by file URLs that are not accessible from inside the plugin_daemon container. On Mac with Docker Desktop, using host.docker.internal for FILES_URL works for most plugins, but some (like Knowledge Pro) expect to access files via the internal Docker network, just like on cloud servers.

To fix this, set both FILES_URL and INTERNAL_FILES_URL to http://api:5001 in your .env file, and make sure your docker-compose.yaml exposes port 5001 for the api service:

services:
  api:
    ...
    ports:
      - "5001:5001"

After updating, restart all containers. This setup matches what works on your colleague's Tencent Cloud server and is the recommended approach for plugins that need internal access to files and the API [source].

Also, in the Knowledge Pro plugin config, set the API base URL to http://api:5001/v1 (not localhost, not your host IP, not host.docker.internal). The plugin_daemon container can always reach api:5001 on the Docker network, but not localhost or your host IP.

If you still see errors, double-check that the plugin_daemon container can resolve and connect to api:5001:5001 (try docker exec -it <plugin_daemon_container> curl http://api:5001/v1/health).

Let me know if you need a concrete example of the .env or docker-compose.yaml!

To reply, just mention @dosu.

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

Dec 23 '25 13:12 dosubot[bot]

@dosu @dosu I have set both FILES_URL and INTERNAL_FILES_URL to http://api:5001 in my .env file and restart all containers. and exposes port 5001 for the api service. Also, in the Knowledge Pro plugin config, I set the API base URL to http://api:5001/v1 but it does not works and the following error occurs:

plugin_daemon container ：

Dec 23 '25 13:12 comaaxl

The "One or more files not found" error in Knowledge Pro means the plugin can't find or access the files referenced by their IDs in the Dify database. This is almost always a network or configuration issue inside Docker.

Your setup—FILES_URL and INTERNAL_FILES_URL both set to http://api:5001, port 5001 exposed, and the Knowledge Pro API base URL set to http://api:5001/v1—is correct for Docker Compose. This matches what works on cloud servers and is the recommended config for plugin file access and API calls (reference, reference).

The 404 errors you see when curling /v1/health are expected—Dify's health check endpoint is /health, not /v1/health (reference). So your containers can reach the API, but the endpoint path is wrong.

If you still get "One or more files not found," double-check these:

The file IDs passed to Knowledge Pro must exist in the Dify database for the current tenant. If the files were uploaded in a different workflow, or the IDs are missing/invalid, you'll get this error (reference).
The plugin_daemon container must be able to reach api:5001 on the Docker network. Try:
```
docker exec -it <plugin_daemon_container> curl http://api:5001/health
```
You should get a JSON response with status "ok".
Make sure your workflow is passing the correct file IDs from the Mineru output to Knowledge Pro. If you can, inspect the JSON input to Knowledge Pro and verify the file IDs are present and match files in the Dify database.

If all of the above checks out and the error persists, it's likely a workflow or data mapping issue—double-check how file IDs are handed off between nodes.

Let me know if you want help inspecting the workflow JSON or debugging the file ID handoff!

To reply, just mention @dosu.

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

Dec 23 '25 14:12 dosubot[bot]

@dosu @dosu

I suspect the issue might be related to the API endpoint address of the service API. I have redeployed a new instance of Dify on a virtual machine with exactly the same plugin parameter configurations, and the Dify on the virtual machine works properly without any issues. The API endpoint address of the Dify knowledge base service API on the virtual machine is http://[virtual machine IP address]/v1.

So, could it be that I need to replace the "localhost" part in the API endpoint address http://localhost/v1 of the Dify service API deployed on my Mac with the "local machine's IP address" or "host.docker.internal"? However, I have no idea which configuration file I can edit to make this change. Could you please tell me?

Dec 24 '25 01:12 comaaxl

Yes, you should replace "localhost" in the API endpoint address with either your Mac's LAN IP or host.docker.internal for Docker Desktop on Mac. This is because "localhost" inside a container refers to the container itself, not your host machine, so plugins and other containers can't reach the API service at that address source.

To change this, edit your .env file and set:

SERVICE_API_URL=http://host.docker.internal:5001/v1
CONSOLE_API_URL=http://host.docker.internal:5001
APP_API_URL=http://host.docker.internal:5001
DIFY_BIND_ADDRESS=0.0.0.0

Or use your LAN IP instead of host.docker.internal if you prefer. Make sure port 5001 is exposed in your docker-compose.yaml for the api service.

After editing the .env file, restart all Docker containers:

docker-compose down
docker-compose up -d

This will update the API endpoint address shown in the UI and make it accessible to plugins and containers source.

You can verify the change by checking the API endpoint in the UI or running:

docker exec -it <plugin_daemon_container> curl http://host.docker.internal:5001/health

Let me know if you need help with the exact .env or docker-compose.yaml setup!

To reply, just mention @dosu.

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

Dec 24 '25 01:12 dosubot[bot]

@dosu @dosu

I have tried all the methods you suggested, but the error still persists. It feels like it’s just not usable at all. I wonder if you have ever tested all Dify functions with a local deployment on a Mac—it really seems to have quite a few issues. o(╥﹏╥)o

Dec 24 '25 05:12 comaaxl

I totally get your frustration—what you’re running into is a common pain point with Docker Desktop on Mac, especially for complex apps like Dify that rely on plugins and internal networking. You’ve already tried all the recommended config changes (FILES_URL, INTERNAL_FILES_URL, SERVICE_API_URL, etc.), but some plugins (like Knowledge Pro) still can’t reliably access files or APIs because of how Docker on Mac handles networking and host/container communication. There aren’t any official platform-specific workarounds in the Dify docs or code for these issues, and the same configs work fine on cloud servers or Linux VMs, which have more predictable networking.

At this point, the most reliable way to get all Dify features and plugins working is to deploy on a Linux VM (locally or in the cloud) or use a remote Docker host. That’s why your colleague’s Tencent Cloud setup works out of the box, while Mac local deployments often hit these weird edge cases. If you want, I can help you set up a Linux VM or walk through your workflow to see if there’s any last thing to try—but for full stability, a Linux-based environment is the best bet.

Let me know if you want step-by-step help with an alternative deployment or if you want to dig deeper into your current workflow!

To reply, just mention @dosu.

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

Dec 24 '25 05:12 dosubot[bot]