Got a dify 404 for requesting a published workflow

[AdaChamberss]

Self Checks

• I have searched for existing issues search for existing issues, 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.

Content

I deployed Dify through a two-layer Nginx setup and published a workflow app. The app‘s url is http://10.xxx.157.36:8080/dify/chat/LP3XqviF1JFORUnT. The prefix 'http://10.xxx.157.36:8080/dify' is for the first nginx layer to forwrad to the dify nginx.
However I checked the logs of dify nginx. It reported:

10.142.157.36 - - [13/Nov/2025:04:31:17 +0000] "GET /chat/LP3XqviF1JFORUnT HTTP/1.0" 404 5710 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36" "10.142.81.41, 10.142.81.40"

[dosubot[bot]]

The 404 error is likely caused by how your two-layer Nginx setup handles the /dify prefix. Dify does not natively support subpath routing via environment variables or runtime config; you need to manually set the basePath and assetPrefix to /dify in both web/utils/var-basePath.js and web/utils/var.ts, then rebuild the frontend Docker image. If you skip this, static assets and routes will 404 because the frontend expects to be served from root, not /dify details.

For the Nginx config: the external (gateway) Nginx should rewrite URLs to strip the /dify prefix before proxying API/backend requests to the internal Dify Nginx, but keep the prefix for frontend/static asset requests. A common cause of 404s is forwarding the full path (e.g., /dify/chat/LP3XqviF1JFORUnT) to the backend, which only recognizes /chat/LP3XqviF1JFORUnT example config.

Checklist:

1. Edit both web/utils/var-basePath.js and web/utils/var.ts to set basePath and assetPrefix to /dify.
2. Rebuild the frontend Docker image and use it in your deployment.
3. In your external Nginx, use a rewrite rule like rewrite ^/dify/(.*)$ /$1 break; for API/backend requests, but do not rewrite for static assets.
4. Set backend environment variables (like CONSOLE_API_URL, APP_WEB_URL) to include /dify if needed, and enable RESPECT_XFORWARD_HEADERS_ENABLED=true for correct URL generation behind proxies reference.

If you still see 404s, double-check that the frontend was rebuilt with the correct basePath and that your Nginx proxy is rewriting and forwarding requests as described.

To reply, just mention @dosu.

---

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

[AdaChamberss]

I have already followed the bot's advise. According to the logs of dify nginx, the url seems to be right: /chat/LP3XqviF1JFORUnT. However the dify nginx seems can't handle this right url. The same thing worked on my own machine: the dify nginx also got a '/chat/xxxxxxxxxxx' url and can work with code 200.
Is the workflow published successfully in the 2 nginx layer condition by simply click the publish button?
Or there's some thing wrong during the requesting session?
@dosu.

[dosubot[bot]]

Publishing a workflow in Dify works by simply clicking the publish button—no extra steps are needed, even with a two-layer Nginx setup. If you’re seeing a 404 for /chat/LP3XqviF1JFORUnT but the same URL works locally, the issue is almost always with how requests are routed and rewritten between your Nginx layers, not with the workflow publishing process itself.

Dify’s backend expects URLs like /chat/<id> at root, not with a /dify prefix. Your external Nginx should rewrite API/backend requests to strip the /dify prefix (e.g., rewrite ^/dify/(.*)$ /$1 break;), but keep the prefix for frontend/static assets. If the rewrite isn’t applied correctly, the backend will return 404 because it doesn’t recognize /dify/chat/<id> as a valid route reference.

Also, make sure your frontend was rebuilt with both basePath and assetPrefix set to /dify in web/utils/var-basePath.js and web/utils/var.ts, and that all relevant environment variables (like CONSOLE_API_URL, APP_WEB_URL) include /dify if needed reference.

If you’ve confirmed the workflow is published in the admin UI and the workflow ID is valid, double-check your Nginx rewrite rules and frontend build. The workflow publishing process itself is atomic and independent of Nginx topology reference. The 404 is almost certainly a routing or proxy config issue.

To reply, just mention @dosu.

---

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

[AdaChamberss]

I am trying to request the published workflow in the local environment where Dify is actually running:
curl http://localhost:5094/chat/LP3XqviF1JFORUnT
I checked the dify nginx logs, the same error happened:

192.168.144.1 - - [13/Nov/2025:07:51:45 +0000] "GET /chat/LP3XqviF1JFORUnT HTTP/1.1" 404 17957 "-" "curl/7.29.0" "-"

So I think it's not the problem of the 2 layer nginx.
@dosu.

[dosubot[bot]]

To access the Dify database (usually PostgreSQL), first check your deployment method:

If using Docker Compose (most common):

1. Find your database container name (often db).
2. Run this command to open a SQL shell inside the container:

   docker compose exec db psql -U postgres -d dify

   Replace db, postgres, and dify if you changed these in your .env or docker-compose.yml (source).

If you want to connect from your host (using a tool like psql or DBeaver):

• Make sure port 5432 is exposed in your docker-compose.yml:

  ports:
    - 5432:5432

• Restart Dify with docker compose up -d.
• Connect to localhost:5432 with username postgres and password difyai123456 (unless you changed these) (source).

If running Postgres outside Docker:
Connect with:

psql -h <host> -p <port> -U <username> <database>

using credentials from your .env or deployment config.

Security tips:
Never expose your database to the public internet. Use strong passwords and restrict access to trusted hosts only.

Once connected, you can run queries like:

SELECT id, version, app_id, tenant_id FROM workflows WHERE id = '<your_workflow_id>';

to check workflow status.

To reply, just mention @dosu.

---

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

[AdaChamberss]

Got an error following the bot's suggestion:

dify=# SELECT id, version, app_id, tenant_id FROM workflows WHERE id = 'LP3XqviF1JFORUnT';
ERROR: invalid input syntax for type uuid: "LP3XqviF1JFORUnT"
LINE 1: ...sion, app_id, tenant_id FROM workflows WHERE id = 'LP3XqviF1...

@dosu.

[dosubot[bot]]

The error happened because the workflows table expects the id column to be a UUID, but 'LP3XqviF1JFORUnT' is not a valid UUID. Dify generates UUIDs for workflow IDs in the database, while the public-facing ID in the URL is a different, non-UUID identifier. There is no column in the workflows table for non-UUID workflow IDs, so you can't query by the URL ID directly—PostgreSQL will always throw a type error if you try this reference.

To find the correct UUID for your workflow, check the Dify admin UI for the workflow's details, or use the API if available. Once you have the UUID, you can query the database using that value. The URL ID and the database UUID are not directly interchangeable.

To reply, just mention @dosu.

---

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

[AdaChamberss]

How to find the UUID? I did not find it in the Dify admin UI.
@dosu.

[dosubot[bot]]

The workflow UUID is not shown directly in the main Dify admin UI. However, you can get it by opening the workflow’s version history interface—there should be a copy icon next to each version entry. Clicking this icon copies the complete workflow ID, which is the internal UUID you need for database queries or API calls details.

If you need to list all workflow UUIDs for a specific app, you can use the Dify API endpoint:
GET /apps/<app_id>/workflows
This returns workflow objects with their internal UUIDs, allowing you to map between public workflow IDs and UUIDs if you know the app ID reference.

The public-facing workflow ID in URLs (like LP3XqviF1JFORUnT) is not the same as the internal UUID used in the database or API responses reference. If you need to query the database, always use the UUID copied from the version history or retrieved via the API.

To reply, just mention @dosu.

---

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

[AdaChamberss]

In fact I did not find a copy icon:

Also it will response a dify 404 page for /apps/LP3XqviF1JFORUnT/workflows as my problem in the begging.
@dosu.

[dosubot[bot]]

The workflow UUID isn’t shown in your admin UI, and querying the database by the public workflow ID (like LP3XqviF1JFORUnT) will always fail because the database expects a UUID and doesn’t store the public ID as a field reference. The copy icon for retrieving the UUID is only available in certain Dify versions—your screenshot confirms it’s missing in your UI.

If the /apps/<app_id>/workflows API endpoint returns a 404, it usually means the app or workflow isn’t published, or there’s a routing/config issue reference. There’s no direct way to map the public workflow ID to the internal UUID from the UI or database in your setup.

Your best options now:

• Double-check the workflow is published and visible in the admin UI.
• Try enabling debug or request logging in the backend (ENABLE_REQUEST_LOGGING=True in .env). When you hit /chat/<public_id>, backend logs may show both the public ID and the internal UUID, which you can use to correlate.
• If you know the app’s internal UUID, you can use the API (GET /apps/<app_id>/workflows) to list all workflows for that app—if this endpoint works, it will show the internal UUIDs.

If none of these work, please share your Dify version—features and UI elements differ between releases, and knowing your version may help find a workaround.

To reply, just mention @dosu.

---

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

[AdaChamberss]

The Dify version is 1.7.0. Set ENABLE_REQUEST_LOGGING=True, but no logs is outputted in the web container nor the api container when requesting /chat/xxxxxxxxx.
The Dify nginx logs outputted a 404 error like the begining:

10.142.157.36 - - [18/Nov/2025:08:09:20 +0000] "GET /chat/LP3XqviF1JFORUnT HTTP/1.0" 404 5708 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36" "10.142.81.41, 10.142.81.40"

@dosu.

[dosubot[bot]]

In Dify v1.7.0, if you set ENABLE_REQUEST_LOGGING=True but see no backend logs for /chat/LP3XqviF1JFORUnT requests, it’s likely because either the request isn’t reaching the backend, or logging isn’t enabled at the right level. The request logging extension only logs if the logger is set to DEBUG level and ENABLE_REQUEST_LOGGING is true—double-check your .env and container configs for both settings. Logs should appear in the api/web container output or /app/logs/server.log if configured (source).

For the persistent 404: the backend expects a workflow UUID, not the public ID from the URL. If the workflow isn’t published, or the ID is wrong, you’ll get a 404 (source). There’s no direct mapping from public IDs to UUIDs in the database, and the admin UI may not show the UUID in your version. If the request is rejected before hitting the backend (for example, by Nginx or due to missing authentication/session), it won’t generate backend logs.

Next steps: confirm your logging level is DEBUG, check your workflow is published and you’re using the correct UUID, and review your Nginx proxy rules to ensure requests reach the backend. If you still see only Nginx 404s and no backend logs, the request is likely not making it to the Dify API service.

To reply, just mention @dosu.

---

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

[AdaChamberss]

How to confirm my logging level is DEBUG？
How to check my workflow is published？
How to check I am using the correct UUID?
@dosu.

[dosubot[bot]]

Here’s how you can check each point in Dify v1.7.0:

1. Confirm logging level is DEBUG:
Check your .env or Docker environment for LOG_LEVEL=DEBUG. You can verify the effective value inside your running container with:

docker compose exec api env | grep LOG_LEVEL

or, from a Python shell in the container:

from configs import dify_config; print(dify_config.LOG_LEVEL)

If set correctly, your logs should include DEBUG-level messages. The logging config uses this variable to set the root logger level at startup (source, source).

2. Check if your workflow is published:
A workflow is published if its version in the database is not 'draft'. You can check this by querying the workflows table with the internal UUID (not the public ID). In the admin UI, published workflows usually show a “Latest Published” timestamp or similar indicator. If you have database access, run:

SELECT id, version FROM workflows WHERE app_id = '<your_app_uuid>' AND version != 'draft';

If you see a row, that workflow is published (source).

3. Check if you are using the correct UUID:
The workflow ID in URLs like /chat/LP3XqviF1JFORUnT is a public-facing ID, not the internal UUID. The database and API require the UUID. In v1.7.0, if the admin UI does not show a copyable UUID in the version history, and the /apps/<app_id>/workflows API endpoint is unavailable or returns 404, there is no direct way to map the public ID to the UUID from the UI. Your best bet is to use the API (if accessible) to list workflows for your app and get their UUIDs, or check the workflow_id field in the apps table for your app’s UUID (source).

If you’re stuck, you may need to upgrade to a newer Dify version where the UI exposes the UUID, or ensure your API endpoints are reachable and permissions are correct.

To reply, just mention @dosu.

---

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

[AdaChamberss]

I found that the published agent can be shown in the workflows table.
@dosu.

[dosubot[bot]]

Yes, that's expected—published agents are stored as entries in the workflows table in Dify. Agents are a type of workflow, so when you publish an agent, it creates a workflow record with its own UUID, type, app_id, and other metadata. The workflows table holds both workflow apps and agent definitions, distinguished by fields like type and version (where published versions are not 'draft') see schema details.

If you need to correlate a published agent with its workflow record, match on app_id, type, and version in the database. The public-facing ID in URLs is not stored in the table; only the internal UUID is used for queries and references. If you want help interpreting specific entries or mapping them to your UI, let me know what details you have!

To reply, just mention @dosu.

---

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

[AdaChamberss]

I found that the published agent can be shown in the workflows table. However I still got 404 in the nginx log when requesting from url, just like my problem in the beginngin:

10.142.157.36 - - [18/Nov/2025:08:09:20 +0000] "GET /chat/LP3XqviF1JFORUnT HTTP/1.0" 404 5708 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36" "10.142.81.41, 10.142.81.40"

Maybe the public-facing ID in the URL is wrong. How can I check it?
@dosu.

[dosubot[bot]]

In Dify v1.7.0, there is no direct way to check or map the public-facing ID used in the /chat/<id> URL (like LP3XqviF1JFORUnT) to the internal workflow UUID stored in the database. The workflows table only stores UUIDs as primary keys, and there is no column for the public ID or any mapping between the two. The admin UI and API in this version do not expose the public-facing ID or provide a way to verify it against the database. If you see your agent in the workflows table but still get a 404 with a given public ID, it likely means the URL ID is incorrect or does not correspond to a published workflow in your environment. There is no backend or database method to confirm the correct public-facing ID—these tokens are managed separately and not stored with the workflow record in v1.7.0.

If you can't retrieve the public ID from the UI or API, your only option is to use the share or publish feature in the Dify UI to generate a new valid public URL for your workflow or agent. If that feature is missing or broken, you may need to upgrade to a newer Dify version where this mapping is exposed or more easily accessible.

Reference: workflow model and service code

To reply, just mention @dosu.

---

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

[AdaChamberss]

How to check which public IDs are valid?
How do Dify work when recieved a public ID? How does Dify get the right app according to the public ID?
@dosu

[AdaChamberss]

How to check which public IDs are valid?
How does Dify work when recieved a public ID? How does Dify get the right app according to the public ID?
@dosu

[dosubot[bot]]

There’s no way in Dify v1.7.0 to list or check all valid public IDs (the short tokens in URLs like /chat/LP3XqviF1JFORUnT)—they aren’t stored in the database or exposed by the API. The only way to know if a public ID is valid is to try accessing it: if it resolves to a published workflow, it’s valid; if not, you get a 404.

When Dify receives a request with a public ID, the frontend (Next.js) validates the token and calls the backend API to resolve it. Internally, Dify links workflows to apps using UUIDs only. When you publish a workflow, Dify writes the workflow’s UUID into the app’s workflow_id field. The public ID is mapped to the correct app and workflow by the frontend and API logic, not by any database field. If the mapping fails (for example, the workflow isn’t published or the token is wrong), you get a 404. There’s no backend or database method to list or verify public IDs directly—validity is determined by whether the token can be resolved to a published workflow at request time.

Here’s a simplified flow:

graph LR
    A["User requests /chat/<public_id>"] --> B["Frontend validates token"]
    B --> C{"Is token valid and published?"}
    C -- Yes --> D["Frontend/API resolves to app/workflow via internal UUID"]
    C -- No --> E["404 Not Found"]

Loading

If you need a valid public URL, use the share or publish feature in the Dify UI to generate it. If that’s missing or broken, upgrading to a newer Dify version may help, as later versions expose more mapping info in the UI and API.

Reference: Dify workflow model and controller code

To reply, just mention @dosu.

---

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

[AdaChamberss]

I regenerated the public url, but still got 404.
@dosu.

[AdaChamberss]

Is it possible that a wrong environment variable in my .env is causing this 404 error?@dosu.

[dosubot[bot]]

Yes, a misconfigured environment variable in your .env can definitely cause 404 errors in Dify—especially for published workflow URLs.

The most critical variables to check are:

• APP_WEB_URL, CONSOLE_API_URL, SERVICE_API_URL, and FILES_URL: These must match your actual public access URL, including the correct port and subpath (like /dify if you use a subpath behind nginx). If they’re wrong, Dify may generate broken links or fail to route requests, resulting in 404s details.
• RESPECT_XFORWARD_HEADERS_ENABLED: Set this to true if you’re behind a proxy. If it’s missing or false, Dify may not correctly interpret proxy headers, which can break routing and URL resolution details.
• Plugin API keys (like PLUGIN_DIFY_INNER_API_KEY, INNER_API_KEY_FOR_PLUGIN): If these are missing or incorrect, plugin and agent endpoints can return 404s details.

For multi-nginx or subpath setups, make sure all backend URLs in .env include the subpath, and that your nginx rewrite rules and proxy headers are correct. Also, remember that frontend routing for subpaths requires rebuilding the frontend with the correct basePath and assetPrefix—just changing .env is not enough for the frontend details.

If you update any of these variables, restart your containers to apply the changes. If you’re still seeing 404s, double-check your nginx config and confirm that requests are reaching the backend as expected.

To reply, just mention @dosu.

---

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

[AdaChamberss]

I can chat with the workflow through 'open in explore' and 'access API reference'. However got 404 for 'run app'. The Dify generated app url is http://10.142.157.36:8080/dify/dify/chat/XKtEZpHYfSjvf1Mx. However I think it should be http://10.142.157.36:8080/dify/chat/XKtEZpHYfSjvf1Mx. Both of them got 404 in the dify nginx logs.
@dosu.