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

HTTP Request Node: [Errno -2] Name or service not known #21193

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

Originally created by @duxuanyu on GitHub (Dec 21, 2025).

Self Checks

  • I have read the Contributing Guide and Language Policy.
  • 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, otherwise it will be closed.
  • 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
  • Please do not modify this template :) and fill in all the required fields.

Dify version

v1.11.1

Cloud or Self Hosted

Self Hosted (Source), Self Hosted (Docker)

Steps to reproduce

Steps to Reproduce

  1. Environment: Self-hosted Dify deployed via Docker on CentOS 7 server
  2. Action 1: Navigate to Dify admin panel → API Configuration → Add third-party API endpoint (e.g., https://xxx.com/api/v1)
  3. Action 2: Set request method to POST, add request header Content-Type: application/json, and fill in valid request body parameters
  4. Action 3: Click "Test Connection" button to trigger API call
  5. Result: API test fails with no data returned; error appears in server logs/browser console

Error Logs/Screenshots

状态
FAIL
运行时间
4.020s
总 token 数
0 Tokens
[Errno -2] Name or service not known

✔️ Expected Behavior

Additional Context

  • Testing public universal API (https://httpbin.org/get) also fails (eliminates target API-specific issues)
  • Server has working external network access (ping baidu.com is successful; rules out general network outage)
  • Confirmed request URL, method, headers, and body format all comply with the target API documentation
  • Dify version: v1.11.1
  • Docker version: 24.0.7

❌ Actual Behavior

When testing the HTTP request node, it returns ‘[Errno -2] Name or service not known’, and the API call fails to resolve the domain or connect to the target service, even though the request URL, method, and body format are correctly configured

Originally created by @duxuanyu on GitHub (Dec 21, 2025). ### Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [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, 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 (Source), Self Hosted (Docker) ### Steps to reproduce ## Steps to Reproduce 1. Environment: Self-hosted Dify deployed via Docker on CentOS 7 server 2. Action 1: Navigate to Dify admin panel → API Configuration → Add third-party API endpoint (e.g., https://xxx.com/api/v1) 3. Action 2: Set request method to POST, add request header `Content-Type: application/json`, and fill in valid request body parameters 4. Action 3: Click "Test Connection" button to trigger API call 5. Result: API test fails with no data returned; error appears in server logs/browser console ## Error Logs/Screenshots 状态 FAIL 运行时间 4.020s 总 token 数 0 Tokens [Errno -2] Name or service not known ### ✔️ Expected Behavior ## Additional Context - Testing public universal API (https://httpbin.org/get) also fails (eliminates target API-specific issues) - Server has working external network access (ping baidu.com is successful; rules out general network outage) - Confirmed request URL, method, headers, and body format all comply with the target API documentation - Dify version: v1.11.1 - Docker version: 24.0.7 ### ❌ Actual Behavior When testing the HTTP request node, it returns ‘[Errno -2] Name or service not known’, and the API call fails to resolve the domain or connect to the target service, even though the request URL, method, and body format are correctly configured
yindo added the 🐞 bug label 2026-02-21 20:11:22 -05:00
yindo closed this issue 2026-02-21 20:11:22 -05:00
yindo commented 2026-02-21 20:11:22 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Dec 21, 2025):

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

This error is a DNS resolution failure inside the Docker container, not a bug in Dify itself. It’s usually caused by Docker network or Squid proxy DNS misconfiguration. Here’s how you can troubleshoot and resolve it:

  1. Test DNS inside the container:
    Run docker exec -it <container_name> ping httpbin.org or curl https://httpbin.org/get from the relevant Dify container (api, worker, or ssrf_proxy) to check if DNS works inside Docker.

  2. Specify DNS servers:
    In your docker-compose.yaml, add a DNS section to the affected services:

    services:
  api:
    ...
    dns:
      - 8.8.8.8
      - 8.8.4.4

    Then restart Docker:
    docker compose down && docker compose up -d

  3. Check Squid proxy config:
    Edit docker/ssrf_proxy/squid.conf.template and add:

    ignore_unknown_nameservers on
dns_timeout 1 seconds
dns_retransmit_interval 1 seconds
dns_defnames off

    Comment out any domain-based ACLs if you’re in a restricted network. Restart the ssrf_proxy container after changes.

  4. Use IP addresses as a workaround:
    If DNS issues persist, use the target API’s IP address in your request URL and set the Host header to the original domain. This bypasses DNS inside Docker and is a reliable workaround source.

  5. Inspect Docker networks:
    Make sure your services are connected to both the internal and default networks if needed. You can check with docker network inspect <network_name>.

  6. Unset proxy environment variables:
    If you have HTTP_PROXY or HTTPS_PROXY set, try unsetting them—they can interfere with internal networking.

If you make changes, always restart the affected containers. These steps should resolve most DNS issues in self-hosted Dify Docker setups on CentOS 7. For more details and examples, see this thread and this workaround.

To reply, just mention @dosu.

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

Chat with Dosu Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Dec 21, 2025): <!-- Greeting --> Hi @duxuanyu! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the dify team. <!-- Answer --> This error is a DNS resolution failure inside the Docker container, not a bug in Dify itself. It’s usually caused by Docker network or Squid proxy DNS misconfiguration. Here’s how you can troubleshoot and resolve it: 1. **Test DNS inside the container:** Run `docker exec -it <container_name> ping httpbin.org` or `curl https://httpbin.org/get` from the relevant Dify container (api, worker, or ssrf_proxy) to check if DNS works inside Docker. 2. **Specify DNS servers:** In your `docker-compose.yaml`, add a DNS section to the affected services: ```yaml services: api: ... dns: - 8.8.8.8 - 8.8.4.4 ``` Then restart Docker: `docker compose down && docker compose up -d` 3. **Check Squid proxy config:** Edit `docker/ssrf_proxy/squid.conf.template` and add: ``` ignore_unknown_nameservers on dns_timeout 1 seconds dns_retransmit_interval 1 seconds dns_defnames off ``` Comment out any domain-based ACLs if you’re in a restricted network. Restart the `ssrf_proxy` container after changes. 4. **Use IP addresses as a workaround:** If DNS issues persist, use the target API’s IP address in your request URL and set the `Host` header to the original domain. This bypasses DNS inside Docker and is a reliable workaround [source](https://github.com/langgenius/dify/issues/23871). 5. **Inspect Docker networks:** Make sure your services are connected to both the internal and default networks if needed. You can check with `docker network inspect <network_name>`. 6. **Unset proxy environment variables:** If you have `HTTP_PROXY` or `HTTPS_PROXY` set, try unsetting them—they can interfere with internal networking. If you make changes, always restart the affected containers. These steps should resolve most DNS issues in self-hosted Dify Docker setups on CentOS 7. For more details and examples, see [this thread](https://github.com/langgenius/dify/issues/18956) and [this workaround](https://github.com/langgenius/dify/issues/17811). <!-- 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/c3e8cdf0-f0a6-4caa-b603-79cef3a080ad?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/c3e8cdf0-f0a6-4caa-b603-79cef3a080ad?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/c3e8cdf0-f0a6-4caa-b603-79cef3a080ad?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/c3e8cdf0-f0a6-4caa-b603-79cef3a080ad?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/c3e8cdf0-f0a6-4caa-b603-79cef3a080ad?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/c3e8cdf0-f0a6-4caa-b603-79cef3a080ad?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/c3e8cdf0-f0a6-4caa-b603-79cef3a080ad?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=This%20error%20is%20a%20DNS%20resolution%20failure%20inside%20the%20Docker%20container%2C%20not%20a%20bug%20in%20Dify%20itself.%20It%E2%80%99s%20usually%20caused%20by%20Docker%20network%20or%20Squid%20proxy%20DNS%20misconfiguration.%20Here%E2%80%99s%20how%20you%20can%20troubleshoot%20and%20resolve%20it%3A%0A%0A1.%20%2A%2ATest%20DNS%20inside%20the%20container%3A%2A%2A%20%20%0A%20%20%20Run%20%60docker%20exec%20-it%20%3Ccontainer_name%3E%20ping%20httpbin.org%60%20or%20%60curl%20https%3A//httpbin.org/get%60%20from%20the%20relevant%20Dify%20container%20%28api%2C%20worker%2C%20or%20ssrf_proxy%29%20to%20check%20if%20DNS%20works%20inside%20Docker.%0A%0A2.%20%2A%2ASpecify%20DNS%20servers%3A%2A%2A%20%20%0A%20%20%20In%20your%20%60docker-compose.yaml%60%2C%20add%20a%20DNS%20section%20to%20the%20affected%20services%3A%0A%20%20%20%60%60%60yaml%0A%20%20%20services%3A%0A%20%20%20%20%20api%3A%0A%20%20%20%20%20%20%20...%0A%20%20%20%20%20%20%20dns%3A%0A%20%20%20%20%20%20%20%20%20-%208.8.8.8%0A%20%20%20%20%20%20%20%20%20-%208.8.4.4%0A%20%20%20%60%60%60%0A%20%20%20Then%20restart%20Docker%3A%20%20%0A%20%20%20%60docker%20compose%20down%20%26%26%20docker%20compose%20up%20-d%60%0A%0A3.%20%2A%2ACheck%20Squid%20proxy%20config%3A%2A%2A%20%20%0A%20%20%20Edit%20%60docker/ssrf_proxy/squid.conf.template%60%20and%20add%3A%0A%20%20%20%60%60%60%0A%20%20%20ignore_unknown_nameservers%20on%0A%20%20%20dns_timeout%201%20seconds%0A%20%20%20dns_retransmit_interval%201%20seconds%0A%20%20%20dns_defnames%20off%0A%20%20%20%60%60%60%0A%20%20%20Comment%20out%20any%20domain-based%20ACLs%20if%20you%E2%80%99re%20in%20a%20restricted%20network.%20Restart%20the%20%60ssrf_proxy%60%20container%20after%20changes.%0A%0A4.%20%2A%2AUse%20IP%20addresses%20as%20a%20workaround%3A%2A%2A%20%20%0A%20%20%20If%20DNS%20issues%20persist%2C%20use%20the%20target%20API%E2%80%99s%20IP%20address%20in%20your%20request%20URL%20and%20set%20the%20%60Host%60%20header%20to%20the%20original%20domain.%20This%20bypasses%20DNS%20inside%20Docker%20and%20is%20a%20reliable%20workaround%20%5Bsource%5D%28https%3A//github.com/langgenius/dify/issues/23871%29.%0A%0A5.%20%2A%2AInspect%20Docker%20networks%3A%2A%2A%20%20%0A%20%20%20Make%20sure%20your%20services%20are%20connected%20to%20both%20the%20internal%20and%20default%20networks%20if%20needed.%20You%20can%20check%20with%20%60docker%20network%20inspect%20%3Cnetwork_name%3E%60.%0A%0A6.%20%2A%2AUnset%20proxy%20environment%20variables%3A%2A%2A%20%20%0A%20%20%20If%20you%20have%20%60HTTP_PROXY%60%20or%20%60HTTPS_PROXY%60%20set%2C%20try%20unsetting%20them%E2%80%94they%20can%20interfere%20with%20internal%20networking.%0A%0AIf%20you%20make%20changes%2C%20always%20restart%20the%20affected%20containers.%20These%20steps%20should%20resolve%20most%20DNS%20issues%20in%20self-hosted%20Dify%20Docker%20setups%20on%20CentOS%207.%20For%20more%20details%20and%20examples%2C%20see%20%5Bthis%20thread%5D%28https%3A//github.com/langgenius/dify/issues/18956%29%20and%20%5Bthis%20workaround%5D%28https%3A//github.com/langgenius/dify/issues/17811%29.)&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/29966)
yindo commented 2026-02-21 20:11:23 -05:00
Author
Owner
Copy Link
Copy Source

@fatelei commented on GitHub (Dec 22, 2025):

this is a dns issue

@fatelei commented on GitHub (Dec 22, 2025): this is a dns issue
yindo commented 2026-02-21 20:11:23 -05:00
Author
Owner
Copy Link
Copy Source

@fatelei commented on GitHub (Dec 22, 2025):

check the docker dns config

@fatelei commented on GitHub (Dec 22, 2025): check the docker dns config
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 🐞 bug
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#21193
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?