Knowledge base can be called in preview, but an error occurs after opening the chat interface.

Discussion
1

In the knowledge base preview, I can call the knowledge base, but it reports an error after opening the chat interface.
What kind of problem is this again, and is there a solution? It appears when switching to a local area network, but I haven’t tested it on the public network, so I don’t know if it’s caused by network address switching.

453069be6b5c9bae384b52d823f47260
453069be6b5c9bae384b52d823f472601920×1080 86.6 KB

2

@Dify_Forum_Helper Take a look.

3

Looking at the English prompt in your screenshot, it roughly says:

Conversation Not Exists. You have requested this URL /console-api/installed-apps/…/messages but did you mean /console-api/installed-apps/{installed_app_id}/messages …

This means that when the frontend opens the chat page, it requested an API address with an incorrect conversation_id or installed_app_id, and the backend couldn’t find the corresponding conversation, thus reporting an error.

Combining your description ‘can call the knowledge base in the knowledge base preview, but an error occurs after opening the chat interface’ and ‘appears after switching to the local area network’, it’s highly suspicious that: the access address or reverse proxy configuration has changed, causing the old URL / session information remembered by the frontend to become invalid.

Below is a set of troubleshooting & resolution steps you can try in order:

1. Start with the Simplest Verification

  1. Switch browsers / open the console in incognito mode → Applications → Chat interface
    • If everything is normal in incognito mode, it’s likely that a conversation_id/URL cached in the browser previously has become invalid.
  2. On the same server, with the same local area network IP, create a brand new application (or duplicate the original application), and directly enter the chat page
    • If the new application works normally, it indicates the problem is focused on old sessions or old links.

2. Clear Browser State

  • Close the current page and clear:
    • The current site’s LocalStorage / SessionStorage
    • The current site’s Cookie & Cache
  • Then log in to Dify again using the new address (e.g., http://internal_IP:port or http://your_local_domain),
    and then open the ‘Conversation’ interface of this knowledge base application.

Many times, after switching from a public domain to an internal IP, the browser still retains session IDs saved under the previous domain,
the frontend still requests the old conversation, and if the backend can’t find it, it will report ‘Conversation Not Exists’.

3. Check ‘Public Domain → Internal Deployment’ Switch

If you are in a scenario like this:

  • Previously accessed via a public domain (e.g., https://xxx.com)
  • Now changed to direct access via a local area network IP or another domain (e.g., http://192.168.x.x:8080)

Please note:

  1. Confirm whether the external access addresses in .env or docker-compose are consistent
    For example, some deployments set environment variables like CONSOLE_API_URL, WEB_URL, CONSOLE_URL.
    If you changed the access method (domain/IP) but these variables still point to the old domain, the frontend might construct the API address incorrectly.
  2. If you are using Nginx / other proxies:
    • Confirm whether the proxy’s path forwarding completely redirects /console-api/installed-apps/* to the backend.
    • Pay attention to whether there are additional path prefixes causing path inconsistency, for example:
      • You access via http://192.168.x.x/dify/, but the reverse proxy does not handle the corresponding prefix.

4. Check if you entered via an ‘Old Link’

Some users might:

  • Have bookmarked an old ‘session URL’ in their browser
  • Or have directly copied a ‘URL from a conversation’ and sent it to others

After you switch networks / change addresses, the ID contained in this link might no longer exist on the backend,
and entering from this link at this point will result in an error similar to the one in your screenshot.

Suggestion:

  1. First, return to the Dify console homepage
  2. Re-enter ‘Applications’ from the left menu → find your application
  3. Click the “Conversation” or “Debug” entry to re-enter, do not use old bookmarks.

5. Backend Logs Can Show More Specific Reasons

If you have permission to view server logs, you can check them at the same time as the error occurs:

  • Check if there is 404 Conversation Not Exists or a similar prompt in the API container logs
  • See if the request path is similar to:
    • /console-api/installed-apps/\u003c某个 id\u003e/messages/\u003c某个 conversation id\u003e
      If the installed_app_id or conversation_id in the path is clearly empty, null, or simply doesn’t exist, it indicates that the frontend used an incorrect ID.

6. If None of the Above Methods Work, You Can Provide This Information

You can add these items to this post, and I can help you diagnose more precisely:

  1. Your Dify version number (bottom right of the console or in the docker-compose image tag)
  2. The full URL format you are currently using to access Dify (e.g., http://192.168.1.100:3000 or with a path prefix)
  3. Is this error:
    • Occurring in the chat interface of all applications, or
    • Only in this one knowledge base application?
  4. Is it: no problem when accessing with a public domain, but an error occurs as soon as you switch to an internal IP, or are both sides experiencing errors?

First, follow steps 1-3: ‘switch browser/incognito + clear cache + re-enter the application from the console’,
many ‘Conversation Not Exists’ errors are caused by old session / old domain caches.
If it still doesn’t work, please paste the environment information above, and we will then investigate configuration and version compatibility.