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

1.17.1 (langgenius/dify-api:1.17.1, langgenius/dify-web:1.17.1)

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

Related: #37780, which was closed as not planned. This report provides a reproduction on 1.17.1 and a verified proxy-level workaround.

Environment: macOS, Docker Desktop, bundled Nginx reverse proxy, Chrome. Dify is exposed on host port 8081; APP_WEB_URL is empty. App identifiers below are placeholders.

1. Deploy Dify with the bundled Nginx proxy and expose its HTTP listener on a non-standard host port, e.g. EXPOSE_NGINX_PORT=8081.
2. Leave APP_WEB_URL unset/empty.
3. Access the console at http://localhost:8081.
4. Create and publish a chat application.
5. Open the Publish menu and click Open Web App.
6. Observe that the generated link omits :8081.

✔️ Expected Behavior

The generated link preserves the browser-facing host and port:

http://localhost:8081/chat/<app-code>

Opening it should load the published application.

❌ Actual Behavior

The generated link is:

http://localhost/chat/<app-code>

It targets port 80 rather than Dify's exposed port 8081. In this environment another local HTTP listener answers with 404. On a host without a port-80 listener, the symptom may instead be a connection failure.

Verified before the workaround:

• Generated console link omitted :8081.
• The port-80 URL returned HTTP 404.
• The same application path at localhost:8081 returned HTTP 200.

Root cause observed in source/configuration

docker/nginx/proxy.conf.template contains:

proxy_set_header Host $host;
proxy_set_header X-Forwarded-Port $server_port;

Nginx $host omits the request port. $server_port represents the internal listener port, which need not equal the externally mapped Docker port.

The application URL fallback uses:

dify_config.APP_WEB_URL or request.url_root.rstrip("/")

This appears in api/models/model.py (Site.app_base_url) and api/controllers/console/app/app.py. With APP_WEB_URL empty, the forwarded request host therefore loses the external port.

Verified local workaround

Changed the Host forwarding directive in both the active Nginx configuration and its persistent template:

-proxy_set_header Host $host;
+proxy_set_header Host $http_host;

Then ran nginx -t successfully, reloaded Nginx, and refreshed the console.

After the change:

• The Open Web App link included localhost:8081.
• Clicking the actual link opened the published chat application.
• The application title, welcome message, existing conversation, and chat input loaded successfully. Verification went beyond the HTTP 200 response; no new model inference was run for this check.

Explicitly setting APP_WEB_URL=http://localhost:8081 is another configuration workaround, but was not applied in this reproduction.

Please consider preserving the external authority (including non-standard port) in the bundled proxy/fallback URL generation, or documenting the required explicit URL setting alongside custom port configuration. The $http_host change above is a locally verified workaround, not a claim that it is sufficient for every reverse-proxy topology.