A working direct URL isolates the failure to the launch path
If an application opens when you type its host IP and port, the container, port publication, and basic LAN route are already functioning. The broken branch is more likely the URL generated by the ZimaOS tile, browser handling of that link, or temporarily stale application metadata.
The community reply proposed that the launcher loaded before Docker and retained an outdated route. That is plausible but was not proven: the user had already restarted Docker and the app manager, a full reboot did not immediately help, and the tiles began working about a day later. Preserve that uncertainty while diagnosing the link itself.
Compare the tile destination with the known-good address
Right-click the tile and copy its link address without opening it. Compare scheme, hostname, IP, port, and path with the manually entered URL that works. A wrong port or old host address points to stale app metadata; an HTTP-versus-HTTPS difference points to proxy or browser security handling.
Open the copied tile URL in a new tab. If it fails with a visible browser error, record that exact result. If clicking produces no tab at all, test pop-up blocking, extension filtering, and the same dashboard in a private window or another browser.
Do not edit container networking until this comparison is complete. If the copied tile address is correct and works when pasted, the problem is the dashboard click event or browser profile. If the copied address is wrong, the problem is upstream in the launcher metadata.
Refresh only the client and metadata layers first
Reload the dashboard without cache, sign out and back in, and test a clean browser profile. Disable page-altering or privacy extensions for the local ZimaOS origin one at a time. These reversible checks should precede host service restarts.
If every clean client receives the same incorrect tile URL, record the app name, displayed port, copied address, working address, and ZimaOS version. Restart the app once and allow the dashboard time to rediscover it. Then perform one orderly ZimaOS reboot as a verification gate, not as proof of a fix.
Avoid unplugging power while storage is active. The original user tried a complete power removal without immediate recovery, so it should not be recommended as the default next step. Do not clear app data or reinstall containers when their direct URLs still work.
Verify container state only if the direct path also begins failing
Check the application status and the published port in ZimaOS. If direct access remains healthy, stop at the launcher boundary. If direct access now fails too, inspect the container's first relevant log error and confirm that its port is still bound to the expected host interface.
Test one affected app and one unaffected app. A single tile with an old port suggests app-specific metadata, while every tile failing in one browser suggests a client issue. Every tile failing across clients after an update is stronger evidence for the app manager or dashboard layer.
After any recovery, repeat the original click test in the same browser, after a dashboard reload, and after one normal reboot. Recovery means the tile consistently opens the same address as the known-good direct URL, not merely that the container status reads “running.”
Escalate with the two URLs instead of resetting the system
If the issue returns, capture the copied tile URL and the manually working URL with private host details redacted as needed. Include timestamps, app name, browser, extensions, ZimaOS version, and whether another client behaves the same way.
Report whether the issue appeared after an app update, port change, host address change, proxy configuration, or ZimaOS upgrade. Those triggers give support a route to reproduce the stale mapping rather than waiting for it to clear again.
Stop before factory reset, app deletion, or broad Docker cleanup while direct access works. The source thread ended with spontaneous recovery and no confirmed cause, so destructive repair would discard evidence without targeting a verified fault.
FAQ
Does restarting Docker rebuild every ZimaOS app link?
The thread does not prove it. The user restarted Docker and the app manager, and the problem remained temporarily.
Why does pasting the tile URL work when clicking does not?
That result isolates browser click handling, extensions, or dashboard JavaScript. Test a private window and another browser before changing the server.
Should I reinstall the affected app?
Not while the direct URL works and data is intact. Compare addresses and collect launcher evidence first.
The original observations and unresolved timeline are in the ZimaOS app tiles discussion.
