langgenius/mineru/mineru plugin fails with "Errno 99: Cannot assign requested address" ConnectError

[huanghuang0913]

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 Dify issues & Dify Official Plugins, 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.13.3

Plugin version

langgenius/mineru@0.5.4

Cloud or Self Hosted

Self Hosted (Source)

Steps to reproduce

Dify version
1.13.3
Cloud or Self Hosted
Self Hosted (Source)
Steps to reproduce
Run self-hosted instance of the platform (Dify)
Create a workflow that uses the langgenius/mineru/mineru plugin node
Execute the workflow that triggers the MinerU plugin call
The workflow immediately aborts with an error
✔️ Expected Behavior
The langgenius/mineru/mineru plugin should run normally, establish a network connection to its backend service, and return the expected result (e.g., document parsing).
The workflow should complete without failure, and the database transaction should commit successfully.
❌ Actual Behavior
The workflow fails with an ABORT strategy due to a ConnectError.
The plugin call throws Errno 99: Cannot assign requested address, indicating the process cannot bind or connect to the required network address.
The database executes a ROLLBACK due to the workflow failure.
Full error logs from the runtime in celery.log:
2026-05-18 05:16:11,753 INFO sqlalchemy.engine.Engine [generated in 0.00038s] {'tenant_id_': 'ea4bc431-0114-4d02-88cc-e624c38b5b136', 'id_': '5a7e73c3-72e6-4275-94b4-1c6f62fd71ac'}
2026-05-18 05:16:11, 760 WARNING [log.py:232] aea0de2979
[on_tool_start] ToolCall:parse-file
('file': File(dify_model_identity='dify_file', id=None, tenant_id='ea4bc431-0114-4d02-88cc-e624c38b5b136', type=<FileType.DOCUMENT: 'document'>, transfer_method=FileTransferMethod.LOCAL_FILE, local_file='', remote_url='http://10.103.43.14:5005/files/8a47490-fdff-48a4-b84f-425bd58f34f/file?preview&timestamp=177908136&nonce=b6f92f200768ebe8f37f9af942389a2&csign=sd64fiaFGiLFv6WCaxQcTam803COo-ihiw6T3_sjUM3D2', related_id='a9a47490-fdff-48a4-b84f-425bd58f34f3f', filename='外贸.pdf', extension='.pdf', mime_type='application/pdf', size=128864))
2026-05-18 05:16:11,789 DEBUG [_trace.py:47] aea0de2979 connect_tcp started host='10.103.43.14' port=5006 local_address=None timeout=600.0 socket_options=None
2026-05-18 05:16:11,769 DEBUG [_trace.py:47] aea0de2979 connect_tcp complete return_value=<httpcore_backends.sync.SyncStream object at 0x7f50f01ccd70>
2026-05-18 05:16:11,770 DEBUG [_trace.py:47] aea0de2979 send_request_headers.started request=<Request [b'POST']>
2026-05-18 05:16:11,770 DEBUG [_trace.py:47] aea0de2979 send_request_headers complete
2026-05-18 05:16:11,770 DEBUG [_trace.py:47] aea0de2979 send_request_body.started request=<Request [b'POST']>
2026-05-18 05:16:11,770 DEBUG [_trace.py:47] aea0de2979 send_request_body complete
2026-05-18 05:16:11,770 DEBUG [_trace.py:47] aea0de2979 receive_response_headers.started request=<Request [b'POST']>
2026-05-18 05:16:26,903 DEBUG [_trace.py:47] aea0de2979 receive_response_headers complete return_value=(b'HTTP/1.1 200, 6 0K', [(b'Content-Type', b'text/event-stream'), (b'Date', b'Mon, 18 May 2026 05:16:26 GMT'), (b'Transfer-Encoding', b'chunked')])
2026-05-18 05:16:26,903 INFO [_client.py:1025] aea0de2979 HTTP Request: POST http://10.103.43.14:5006/plugin/ea4bc431-0114-4d02-88cc-e624c38b5b136/dispatch/invoke "HTTP/1.1 1 200 OK"
2026-05-18 05:16:26,904 DEBUG [_trace.py:47] aea0de2979 receive_response_body.started request=<Request [b'POST']>
2026-05-18 05:16:26,905 ERROR [base.py:305] aea0de2979 Error in stream response for plugin ('code': -500, 'message': '{"message":"{"args":{},"error_type":"ConnectError","message":"[Errno 99] Cannot assign requested address"}"}', 'error_type':PluginInvokeError", 'args':null}', 'data': None}
2026-05-18 05:16:26,906 DEBUG [_trace.py:47] aea0de2979 receive_response_body. failed exception=GeneratorExit()
2026-05-18 05:16:26,906 DEBUG [_trace.py:47] aea0de2979 response_closed. started
2026-05-18 05:16:26,906 DEBUG [_trace.py:47] aea0de2979 response_closed. complete
2026-05-18 05:16:26,907 INFO sqlalchemy.engine.Engine ROLLBACK
2026-05-18 05:16:26,943 ERROR [error_handler.py:101] Node 1778034797725 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 99] Cannot assign requested address
2026-05-18 05:16:26,943 ERROR [debug_logging.py:172] ✗ Node failed: 1778034797725
2026-05-18 05:16:26,943 ERROR [debug_logging.py:173] 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 99] Cannot assign requested address
2026-05-18 05:16:26,943 ERROR [debug_logging.py:176] Details: An error occurred in the langgenius/mineru/mineru, please contact the author of langgenius/mineru/mineru for help, error type: ConnectError, error details: [Errno 99] Cannot assign requested address
I opened the issue here, but it is closed:
langgenius/dify#36311

[huanghuang0913]

I tried to start ssrf proxy container, but the same error.

[dosubot]

The issue persists even with the SSRF proxy container running because the problem isn't about the proxy being absent — it's about how the proxy is configured. Specifically, the Squid-based SSRF proxy has a tcp_outgoing_address 0.0.0.0 directive (introduced in PR #33556) that forces all outbound connections to bind to IPv4 0.0.0.0. In certain network environments, this binding fails with Errno 99: Cannot assign requested address [1].

Since direct connections from the plugin daemon container work fine (e.g., curl succeeds), but requests routed through the SSRF proxy fail, the fix needs to target the Squid proxy configuration itself. Try these workarounds:

1. Remove the IPv4 binding — Edit docker/ssrf_proxy/squid.conf.template and comment out or remove the line tcp_outgoing_address 0.0.0.0, then restart the SSRF proxy container.

2. Allow local network access — Add http_access allow localnet before the deny-all rule in squid.conf.template, since the SSRF proxy blocks private/local network addresses by default [2].

3. Bypass the proxy for MinerU — Set NO_PROXY to include the MinerU service host so that requests to it skip the SSRF proxy entirely [2].

The root cause is a network/proxy configuration issue rather than a bug in the MinerU plugin itself — the same plugin works fine in remote mode on cloud.dify.ai [1].

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[huanghuang0913]

I tried option 1 and 2, nothing changed., same error. Could you give me more details for option 3?@dosu

[dosubot]

Since options 1 and 2 didn't help, the issue may be deeper than the Squid ACL configuration — it's likely that the plugin itself is making outbound HTTP requests that are being routed through the SSRF proxy via environment variables inherited by the plugin daemon container.

The MinerU plugin uses requests and httpx libraries directly [1], and these libraries respect system proxy environment variables (HTTP_PROXY/HTTPS_PROXY) by default. So even if the Squid config allows the traffic, the proxy binding (tcp_outgoing_address 0.0.0.0) still triggers the Errno 99.

Here's what to try:

Set NO_PROXY on the plugin daemon container to bypass the SSRF proxy for your MinerU service host. In your docker-compose.yaml (or .env file), add to the plugin_daemon service:

plugin_daemon:
  environment:
    HTTP_PROXY: ""
    HTTPS_PROXY: ""
    NO_PROXY: "10.103.43.14"  # Replace with your MinerU service IP

Or alternatively, unset the proxy variables entirely for the plugin daemon container if you want plugins to connect directly without any proxy [2]:

plugin_daemon:
  environment:
    HTTP_PROXY: ""
    HTTPS_PROXY: ""
    http_proxy: ""
    https_proxy: ""

After editing, restart with docker compose up -d plugin_daemon.

If that still doesn't resolve it, the Errno 99 may be a host-level networking issue (e.g., the container's network namespace can't bind to the requested address). In that case, check whether the plugin daemon container can directly reach your MinerU service:

docker exec <plugin_daemon_container> curl http://10.103.43.14:8888/docs

If that fails with the same error, the problem is Docker networking rather than proxy configuration.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[huanghuang0913]

root@tmpl gtxtadmin]# docker exec dify-plugin-daemon-1133 curl http://10.103.43.18:8085/docs
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1006 100 1006 0 0 472 0 0:00:02 0:00:02 --:--:-- 491k

<title>FastAPI - Swagger UI</title>

<script src="https://cdn.jsdelivr.net/npm/swagger-ui-dist@5/swagger-ui-bundle.js"></script> <script> const ui = SwaggerUIBundle({ url: '/openapi.json', "dom_id": "#swagger-ui", "layout": "BaseLayout", "deepLinking": true, "showExtensions": true, "showCommonExtensions": true, oauth2RedirectUrl: window.location.origin + '/docs/oauth2-redirect', presets: [ SwaggerUIBundle.presets.apis, SwaggerUIBundle.SwaggerUIStandalonePreset ], }) </script>

@dosu

[huanghuang0913]

with option 3, nothing changed.

[dosubot]

Good news — this confirms the plugin daemon container can reach your MinerU service directly (curl to http://10.103.43.18:8085/docs works fine). So the Docker networking itself is not the problem.

This is interesting because plugin HTTP requests from the MinerU plugin also go directly from the plugin daemon container — they do not route through the SSRF proxy [1]. The plugin daemon explicitly sets trust_env=False, meaning it ignores proxy environment variables.

Since the container can reach MinerU but the plugin still gets Errno 99, this narrows it down to something specific about how the plugin makes the request at runtime. A few things to check:

1. Verify the base_url configured in the plugin — Make sure the MinerU plugin's base_url setting in the Dify UI matches http://10.103.43.18:8085 (the same address you just successfully curled).

2. Check for proxy env vars leaking into the plugin process:

   docker exec dify-plugin-daemon-1133 env | grep -i proxy

   If you see HTTP_PROXY or HTTPS_PROXY set, those could be interfering with the requests library used by the plugin (even though the daemon's own client ignores them, the plugin's requests calls might still pick them up).

3. Check if the error is actually from a different connection — Looking at your original logs, the ConnectError is reported by the plugin daemon at 10.103.43.14:5006 (the Dify→plugin daemon communication), not from the plugin→MinerU connection. Could you confirm: is 10.103.43.14:5006 your plugin daemon address, and is 10.103.43.18:8085 your MinerU service?

The Errno 99 might actually be happening when the MinerU plugin tries to download the file from Dify (the remote_url in your logs points to http://10.103.43.14:5005/files/...), not when connecting to the MinerU parsing service. Can you also test:

docker exec dify-plugin-daemon-1133 curl "http://10.103.43.14:5005"

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[huanghuang0913]

I can see the log from minerU server: INFO: 10.103.43.14:59730 - "GET /docs HTTP/1.1" 200 OK by running docker exec dify-plugin-daemon-1133 curl http://10.103.43.18:8085/docs
docker exec dify-plugin-daemon-1133 curl “http://10.103.43.14:5005/files/8a47490-fdff-48a4-b84f-425bd58f34f/file?preview&timestamp=177908136&nonce=b6f92f200768ebe8f37f9af942389a2&csign=sd64fiaFGiLFv6WCaxQcTam803COo-ihiw6T3_sjUM3D2” is fine, I can download the file with this url.

docker exec dify-plugin-daemon-1133 env | grep -i proxy
HTTP_PROXY=
HTTPS_PROXY=

docker exec dify-plugin-daemon-1133 curl "http://10.103.43.14:5005"
404 NOT Found @dosu

[dosubot]

Thanks for testing — this is very helpful. The curl commands work fine directly from the plugin daemon container, which tells us the network path is fine at the OS/container level. The issue is that the plugin's HTTP requests are being routed through the SSRF proxy, which is where the Errno 99 originates.

Here's what's happening: when the MinerU plugin runs, it needs to download the file from the Dify API (the remote_url like http://10.103.43.14:5005/files/...). This download goes through the SSRF proxy (Squid), which enforces tcp_outgoing_address 0.0.0.0 — and that binding fails in your network environment [1]. Direct curl works because it bypasses the proxy entirely.

Since you're running Self Hosted (Source), the fix is different from Docker Compose deployments. Try this:

Unset the SSRF proxy URLs in your Dify environment configuration so that plugin HTTP calls go direct rather than through Squid:

SSRF_PROXY_HTTP_URL=
SSRF_PROXY_HTTPS_URL=

Or if you still want the SSRF proxy for security but need to fix the binding issue, find your Squid config and remove or comment out:

tcp_outgoing_address 0.0.0.0

Then restart your SSRF proxy service.

You mentioned you already tried editing the Squid config (option 1 from earlier). Can you double-check that the tcp_outgoing_address 0.0.0.0 line is actually gone from the running Squid configuration? You can verify with:

docker exec <ssrf_proxy_container> cat /etc/squid/squid.conf | grep tcp_outgoing

If it's still present, the template might be regenerating it on restart. Also, since you're running from source, confirm how the SSRF proxy environment variables are set — check SSRF_PROXY_HTTP_URL and SSRF_PROXY_HTTPS_URL in your API service config.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.