Myopenhab.org remote access intermittently returns empty 200 responses with no Content-Type — remote MainUI blank, app reports "empty sitemap list" (local works, notifications work)

Apps & Services myopenHAB
1

Goal

Remote access to my openHAB instance via myopenhab.org (MainUI in the Android app and in a desktop browser via home.myopenhab.org). This has worked for years and broke recently — I want to find out whether this is a server-side issue of the remote access proxy or something on my side that I have overlooked.

Environment

  • openHAB 5.2.1-1 (Debian package on x86 Linux, Java 21, bare metal, no Docker)
  • openHAB Cloud Connector: misc-openhabcloud 5.2.1, default configuration (no mode set, which keeps remote access enabled per the connector source)
  • Single instance; UUID and secret unchanged since Dec 2023; instance registered in my myopenhab.org account and shown online
  • Android app (current version) on Android 16; Firefox on desktop Linux
  • The system was on 5.2.0-M2 briefly, then 5.1.4 for some weeks, and has been on 5.2.1 stable since August. I cannot pin down the exact date when remote access last worked — it is used less frequently than local access, so it may have been broken for a while unnoticed.
  • myopenhab.org currently serves via nginx/1.31.3 (X-Powered-By: Express on the API paths)

Symptoms

  • Local/LAN access works perfectly: MainUI, REST, everything.
  • Remote access is broken from every network I tested (home network and cellular, so it is not my local network): MainUI stays blank/empty, the Android app shows “openHAB schickte eine leere Sitemap-Liste” (openHAB returned an empty sitemap list).
  • Push notifications still work — they are delivered reliably, so the cloud connector tunnel itself is up.
  • The failure is intermittent per request, not per session: the same URL sometimes returns a proper response and sometimes a 200 with an empty body and no Content-Type header.

Evidence

1) Android app log (okhttp): the identical request succeeds once and fails one second later

First call returns the correct body:

09-26 14:31:53.044 okhttp: <-- 200 https://myopenhab.org/rest/sitemaps (87ms)
09-26 14:31:53.044 okhttp: content-type: application/json
09-26 14:31:53.046 ServerProperties: Server returned sitemaps: []

([] is correct here — this installation uses MainUI pages only and has no classic sitemaps; locally /rest/sitemaps also returns [].)

The identical request one second later returns an empty body with no content-type:

09-26 14:31:54.765 okhttp: <-- 200 https://myopenhab.org/rest/sitemaps (81ms)
09-26 14:31:54.765 okhttp: x-powered-by: Express
(no content-type, no body)
09-26 14:31:54.769 E ServerProperties: Failed parsing sitemap JSON
09-26 14:31:54.769 E ServerProperties: org.json.JSONException: End of input at character 0 of

2) MainUI webview (inside the Android app): REST JSON arrives broken, module scripts blocked

AbstractWebViewFragment: Uncaught (in promise) parseerror -- From line 0 of https://home.myopenhab.org/overview/
AbstractWebViewFragment: Failed to load module script: Expected a JavaScript-or-Wasm module script but the server responded with a MIME type of "".
AbstractWebViewFragment: TypeError: Failed to fetch dynamically imported module: https://home.myopenhab.org/assets/oh-grid-row-DgLZONrz.js
AbstractWebViewFragment: Failed to load module script: ... MIME type of "" ... https://home.myopenhab.org/assets/oh-trend-CddJZi-u.js

The overview page therefore cannot render → blank page. Notably the large entry bundle assets/index-BJBtX3R_.js (767 kB) downloaded and executed fine in the same session (“App initialization: 76.20 ms – From line 17617 of …index-BJBtX3R_.js”).

3) Firefox desktop console on https://home.myopenhab.org/overview/ (tested from two different networks, including cellular)

Loading module from "https://home.myopenhab.org/assets/useModelStore-HzCUcAGf.js" was blocked because of a disallowed MIME type ("")
Loading module from "https://home.myopenhab.org/assets/addon-store-BWskFyH0.js" was blocked because of a disallowed MIME type ("")
GET https://home.myopenhab.org/assets/useWidgetAction-CiT5U9OC.js  → NS_ERROR_CORRUPTED_CONTENT
GET https://home.myopenhab.org/assets/empty-state-placeholder-DcIkS7jc.js → NS_ERROR_CORRUPTED_CONTENT
GET https://home.myopenhab.org/assets/addon-store-BWskFyH0.js → NS_ERROR_CORRUPTED_CONTENT

The same URL sometimes loads fine (several of the blocked modules succeeded on a retry with HTTP/2 200), and the delivered minified CSS contains corruption artifacts such as text-overflow:ellpsis and width:100/3vw — values that are not in the original build on my server.

4) The served content originates from my instance and is intact locally

The asset hashes requested through the tunnel (index-BJBtX3R_.js, useModelStore-HzCUcAGf.js, …) all exist on my local openHAB and are served correctly there:

$ curl -so /dev/null -w '%{http_code} type=%{content_type} size=%{size_download}\n' \
    http://localhost:8080/assets/index-BJBtX3R_.js
200 type=application/javascript size=767067

Also reproducible server-side: an unauthenticated request to https://home.myopenhab.org/ answers 401 without any Content-Type, while https://myopenhab.org/ answers with content-type: text/html; charset=utf-8 (same nginx).

What I have already tried

  • Verified the cloud connector configuration (empty = defaults; per the 5.2.1 connector source, remote access stays enabled when mode is unset)
  • Cleared /var/lib/openhab/cache and /var/lib/openhab/tmp and did a clean restart — no change
  • Verified UUID/secret are unchanged and there is only one instance connecting (no duplicate connector)
  • Reproduced the failure from two independent networks (home + cellular) with three different clients (Firefox, Android app webview, the app’s own okhttp stack)
  • https://myopenhab.org/health returns 200; the connector log shows “Connected to the openHAB Cloud service”, with occasional short “already connected” reconnect bursts after server-side websocket drops (roughly 8–12 connect/disconnect log events per day)
  • Local MainUI and all REST endpoints remain healthy throughout — the corruption/emptiness appears exclusively on the proxied remote path

Related reports I found

Question

To me this looks like a server-side issue of the remote access proxy: intermittently, response bodies arrive empty (or corrupted) with the Content-Type header stripped, in particular under parallel request load — which would explain blank MainUI pages and the app’s “empty sitemap list” while notifications and occasional requests keep working.

  • Is this a known issue with the current myopenhab.org infrastructure?
  • Are others seeing the same pattern (working notifications + broken remote UI)?
  • Is there anything else I can collect from the cloud connector side (debug logs?) that would help pin this down?
2

Follow-up with hard evidence narrowing this down to the remote proxy’s response delivery:

  • Local server verified healthy: loopback captures (tcpdump -i lo 'tcp port 8080') show every request answered correctly — 200 with full body and correct Content-Type, or a proper 304 on revalidation. MainUI works perfectly on LAN, all assets byte-identical.
  • Connector verified innocent: comparing the TLS upload of the cloud connector’s single Socket.IO connection (ss -ti bytes_sent delta) against the locally delivered response bytes in the same window: 216,237 bytes uploaded vs. 202,411 bytes locally delivered (~7% WebSocket framing overhead). Nothing is lost between openHAB and the cloud service.
  • Client-side effect remains: the first remote MainUI load needs several retries until it renders. Measured on one session: 128 unique modules took 366 GETs — an average of 3 attempts per module, single modules up to 8–12 attempts. 304 responses and some chunked/gzip bodies apparently arrive at the browser empty or header-stripped, which the browser treats as failed module imports (blank/fragmented page, unresolved i18n keys like home.overview.title).
  • Observation: myopenhab.org currently resolves to multiple server IPs (152.53.189.228 and 159.195.27.x, nginx/1.31.3). Instances that reconnect daily (e.g. openHAB stopped nightly for backups) land on different servers via DNS — symptom severity varies accordingly between sessions.

Conclusion: the loss happens between the cloud service and the client, not in users’ openHAB installations. Happy to share the pcap methodology and numbers if that helps tracking it down.

(Separately fixed on my side: the app’s default mainUiStartPage=/Overview (capital O) hits a case-sensitive 404 on openHAB 5.2.1 — /overview works. That alone caused the completely blank overview tile.)

3

8 days later, the problem disappeared for the time being, reason unknown.