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

dify-web Not Listening on 0.0.0.0 Causes Connection Timeouts in Kubernetes #9362

New Issue
Closed
opened 2026-02-21 18:33:47 -05:00 by yindo · 0 comments
yindo commented 2026-02-21 18:33:47 -05:00
Owner
Copy Link
Copy Source

Originally created by @lybym on GitHub (Mar 5, 2025).

Self Checks

  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit report (我已阅读并同意 Language Policy).
  • [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:）
  • Please do not modify this template :) and fill in all the required fields.

Provide a description of requested docs changes

I am experiencing an issue with the official image langgenius/dify-web:1.0.0 when deployed on Kubernetes. Despite setting the environment variable HOST=0.0.0.0 in the Deployment, the dify-web (Next.js) application does not appear to bind to all network interfaces on IPv4.

Details:

Deployment & Service Setup:
The dify-web container is deployed as part of a Kubernetes cluster. The dify-web Service has a ClusterIP with an endpoint such as 192.168.100.188:3000.

Observed Behavior:

Inside the dify-web Pod, the application logs show that Next.js is started via PM2 in cluster mode. The log output displays a “Local” address using the Pod’s hostname (e.g., http://dify-web-644c78f6b4-vt7r2:3000) and a “Network” address with an IPv6 address.
When testing connectivity from within a busybox Pod using wget -qO- http://dify-web:3000, the connection times out.
Testing directly within the dify-web Pod (e.g., wget -qO- http://0.0.0.0:3000) results in “connection refused”, indicating the app isn’t actually listening on IPv4 0.0.0.0.
Expected Behavior:
The application should bind to all network interfaces (0.0.0.0), making it reachable via the Service’s IPv4 endpoint.

Workaround Considered:
Building a custom image based on langgenius/dify-web:1.0.0 and overriding the CMD with something like:

dockerfile
FROM langgenius/dify-web:1.0.0
CMD ["next", "start", "-H", "0.0.0.0", "-p", "3000"]
appears to be a potential workaround. However, I would prefer to use the official image directly if possible.

Questions:

Is there a recommended way to force the dify-web application (or Next.js via PM2) to bind explicitly to 0.0.0.0 using environment variables or configuration files?
Could the default startup command in the official image be modified to ensure proper IPv4 binding, or can documentation be provided on how to override this behavior?
Any help to resolve this would be greatly appreciated.

Originally created by @lybym on GitHub (Mar 5, 2025). ### Self Checks - [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 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. ### Provide a description of requested docs changes I am experiencing an issue with the official image langgenius/dify-web:1.0.0 when deployed on Kubernetes. Despite setting the environment variable HOST=0.0.0.0 in the Deployment, the dify-web (Next.js) application does not appear to bind to all network interfaces on IPv4. Details: Deployment & Service Setup: The dify-web container is deployed as part of a Kubernetes cluster. The dify-web Service has a ClusterIP with an endpoint such as 192.168.100.188:3000. Observed Behavior: Inside the dify-web Pod, the application logs show that Next.js is started via PM2 in cluster mode. The log output displays a “Local” address using the Pod’s hostname (e.g., http://dify-web-644c78f6b4-vt7r2:3000) and a “Network” address with an IPv6 address. When testing connectivity from within a busybox Pod using wget -qO- http://dify-web:3000, the connection times out. Testing directly within the dify-web Pod (e.g., wget -qO- http://0.0.0.0:3000) results in “connection refused”, indicating the app isn’t actually listening on IPv4 0.0.0.0. Expected Behavior: The application should bind to all network interfaces (0.0.0.0), making it reachable via the Service’s IPv4 endpoint. Workaround Considered: Building a custom image based on langgenius/dify-web:1.0.0 and overriding the CMD with something like: dockerfile FROM langgenius/dify-web:1.0.0 CMD ["next", "start", "-H", "0.0.0.0", "-p", "3000"] appears to be a potential workaround. However, I would prefer to use the official image directly if possible. Questions: Is there a recommended way to force the dify-web application (or Next.js via PM2) to bind explicitly to 0.0.0.0 using environment variables or configuration files? Could the default startup command in the official image be modified to ensure proper IPv4 binding, or can documentation be provided on how to override this behavior? Any help to resolve this would be greatly appreciated.
yindo closed this issue 2026-02-21 18:33:47 -05:00
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
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#9362
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?