This source has a simple final result: changing the ZimaOS WebUI away from ports 80/443 broke Zima App 2.3.0 connectivity on the user's ZimaBoard 2, but after updating ZimaOS to version 1.5 the user returned and said the problem was fixed.
That means the page should not teach current users to manually configure a hidden “ZimaClient port” based on the 2025 failure. It was a historical compatibility issue between the client and a customized WebUI port, and the source itself establishes the 1.5 recovery boundary.
The User Changed Ports for Nginx Proxy Manager
Nginx Proxy Manager normally needs host ports 80 and 443 for HTTP/HTTPS entry traffic. The user therefore moved ZimaOS to:
[gateway]
port = 8080
[ssl]
enabled = true
port = 30443and restarted the CasaOS/ZimaOS gateway service.
The Windows Zima App Then Could Not Connect
The source environment was:
- ZimaBoard 2 1664;
- ZimaOS kernel 6.12.25;
- Zima App 2.3.0 on Windows 11.
After the WebUI port change, restarting the Windows app and trying to reconnect failed.
IceWhale Asked for Reproducible Details Rather Than Guessing a Port Setting
Zima-Giorgio asked the user to provide the exact problem description, reproduction steps, previous changes, attempted fixes, hardware, OS version, and client version. This is good evidence handling because the same visible connection failure can result from discovery, remote access, TLS, port, or client-version problems.
Updating to ZimaOS 1.5 Fixed the Source Case
Three days later, ThomasSpi posted: “After update to Zima OS 1.5 it works. Problem fixed.”
That is the strongest source conclusion and should replace speculation about manually teaching Zima App a custom port.
Current ZimaClient Has Continued to Evolve
Current IceWhale documentation describes ZimaClient as automatically finding the fastest usable connection to the WebUI across LAN, external network, hotspot, and other supported paths.
Use the current ZimaClient installation and connection model before recreating a 2.3.0-era fix.
ZimaOS 1.7.1 Further Improved Docker Web URL and Dynamic Network Handling
The 1.7.1 changelog includes more flexible Docker Web URL port configuration and improved URL handling for dynamic network environments. Those changes relate to application URLs rather than proving anything specific about the old ZimaClient bug, but they show the platform's port/URL handling has continued to evolve.
Reverse Proxy and ZimaClient Are Separate Access Paths
Nginx Proxy Manager can provide friendly HTTPS domains for apps or even the ZimaOS dashboard. ZimaClient uses its own discovery/remote-access logic. A reverse-proxy change should not be assumed to reconfigure ZimaClient automatically on every version.
If You Proxy the ZimaOS Dashboard, Preserve WebSockets
A later 2026 community case showed that the dashboard could visually load through Nginx Proxy Manager while live widgets and app dialogs failed until WebSocket Support was enabled. Port conflict and WebSocket proxying are separate layers.
A Safer Way to Change the WebUI Port
- Record the original port.
- Change the WebUI port through the supported UI when available.
- Verify direct browser access at the new IP:port.
- Restart/update ZimaClient and confirm discovery.
- Only then assign 80/443 to the reverse proxy.
- Keep a local recovery path if the proxy/client both fail.
ZimaClient Port Change FAQ
Did the source user find a manual Zima App custom-port setting?
No. The thread ended with the OS update fixing the problem.
Which version fixed the source case?
The user explicitly reported that ZimaOS 1.5 fixed it.
Should current users assume ZimaClient 2.3.0 behavior still applies?
No. Current ZimaClient and ZimaOS connection handling are substantially newer.
