Node-Red Editor Sometimes Hangs on Load over Webrelay

deekerman commented

2026-02-20 09:31:04 -05:00

Owner

Originally created by @SecareLupus on GitHub (Oct 16, 2024).

Originally assigned to: @si458 on GitHub.

Describe the bug
When loading NodeRed Code Editor via Webrelay, the page will often stall midway through its loading screen. This issue seems to only happen via WebRelay and not other access methods (remote-it relay, access within LAN).

To Reproduce
Steps to reproduce the behavior:

Install Nodered on Raspberry Pi
Populate with complex project. (maybe not related)
Install MeshCentral on Raspberry Pi
Set HTTP alternate port to Nodered
Open Webrelay
Observe Nodered top bar & background load. Loading bar loads and begins to fill before stopping part of the way.
Refreshing the page an indeterminate number of times occasionally will finish loading the page.

Expected behavior
Loading bar should fill up quickly and shift the body of the page to include the Flow editor and current project.

Screenshots

Server Software (please complete the following information):

OS: Ubuntu LXC on Proxmox
Virtualization: Docker
Network: WAN mode, Behind NGINX Proxy Manager, which manages SSL
Version: 1.1.32
Node: 20.10.0

Client Device (please complete the following information):

Device: Desktop Workstation
OS: Windows 11
Network: Local to Meshcentral
Browser: Chrome
MeshCentralRouter Version: N/A

Remote Device (please complete the following information):

Device: Raspberry Pi
OS: Raspberry Pi OS bookworm, 64-Bit
Network: Happens both locally and across WAN.
Current Core Version (if known): Nov 21 2022, 2018810399

Additional context
We've tried to reproduce the issue via a Remote.it relay, as well as local access, and the issue seems to only happen when accessed via MeshCentral webrelay. It is not consistent, no logs appear in the browser console, but several media objects seem to stall with "pending" status. Nodered's logs do fire a "Connection Refused" error on hang, but without specification as to why. It's possible that this issue is with NodeRed, but since the presentation seems exclusive to Meshcentral, I wanted to see if it was possibly something about the how the relay communicates with the remote webserver. It feels like a similar experience to #4369.

This has occurred across several remote devices and several client devices. On client devices, we've replicated the issue using Chrome on Windows, and Chrome & Safari on Mac. For remote devices, this has happened on multiple Raspberry Pi devices, as well as an Intel NUC running Ubuntu 23.04. All types of remote devices we currently field have exhibited some sort of inconsistent hang-on-load issue in this manner.

Your config.json file

{
  "$schema": "http://info.meshcentral.com/downloads/meshcentral-config-schema.json",
  "settings": {
    "cert": "mesh.$DOMAIN.com",
    "_WANonly": true,
    "_LANonly": true,
    "sessionKey": "$PASSWORD",
    "port": 443,
    "_aliasPort": 443,
    "redirPort": 80,
    "_redirAliasPort": 80,
    "RelayDNS": "relay.mesh.$DOMAIN.com",
    "AgentPong": 300,
    "TLSOffload": false,
    "trustedProxy": "$PROXY_IP,$ROUTER_IP",
    "SelfUpdate": false,
    "allowLoginToken": true,
    "allowFraming": true,
    "mongodb": "mongodb://mongodb:27017/mesh",
    "mongodbcol": "mesh",
    "WebRTC": true,
    "desktopMultiplex": true,
    "cookieIpCheck": "none",
    "sessionSameSite": "lax",
    "plugins": { "enabled": true }
  },
  "domains": {
    "": {
      "title": "$COMPANY",
      "title2": "Internal Mesh",
      "_minify": true,
      "NewAccounts": "false",
      "_userNameIsEmail": true,
      "certUrl": "https://$PROXY_IP:443",
      "passwordRequirements": {
        "force2factor": true,
	"autofido2fa": true
      }
    }
  },
  "_letsencrypt": {
    "__comment__": "Requires NodeJS 8.x or better, Go to https://letsdebug.net/ first before>",
    "_email": "myemail@mydomain.com",
    "_names": "myserver.mydomain.com",
        "production": false
  }
}

Originally created by @SecareLupus on GitHub (Oct 16, 2024). Originally assigned to: @si458 on GitHub. **Describe the bug** When loading NodeRed Code Editor via Webrelay, the page will often stall midway through its loading screen. This issue seems to only happen via WebRelay and not other access methods (remote-it relay, access within LAN). **To Reproduce** Steps to reproduce the behavior: 1. Install Nodered on Raspberry Pi 2. Populate with complex project. (maybe not related) 3. Install MeshCentral on Raspberry Pi 4. Set HTTP alternate port to Nodered 5. Open Webrelay 6. Observe Nodered top bar & background load. Loading bar loads and begins to fill before stopping part of the way. 7. Refreshing the page an indeterminate number of times occasionally will finish loading the page. **Expected behavior** Loading bar should fill up quickly and shift the body of the page to include the Flow editor and current project. **Screenshots** ![image](https://github.com/user-attachments/assets/77a2091f-969e-4463-809b-365ce6773151) **Server Software (please complete the following information):** - OS: Ubuntu LXC on Proxmox - Virtualization: Docker - Network: WAN mode, Behind NGINX Proxy Manager, which manages SSL - Version: 1.1.32 - Node: 20.10.0 **Client Device (please complete the following information):** - Device: Desktop Workstation - OS: Windows 11 - Network: Local to Meshcentral - Browser: Chrome - MeshCentralRouter Version: N/A **Remote Device (please complete the following information):** - Device: Raspberry Pi - OS: Raspberry Pi OS bookworm, 64-Bit - Network: Happens both locally and across WAN. - Current Core Version (if known): Nov 21 2022, 2018810399 **Additional context** We've tried to reproduce the issue via a Remote.it relay, as well as local access, and the issue seems to only happen when accessed via MeshCentral webrelay. It is not consistent, no logs appear in the browser console, but several media objects seem to stall with "pending" status. Nodered's logs do fire a "Connection Refused" error on hang, but without specification as to why. It's possible that this issue is with NodeRed, but since the presentation seems exclusive to Meshcentral, I wanted to see if it was possibly something about the how the relay communicates with the remote webserver. It feels like a similar experience to #4369. This has occurred across several remote devices and several client devices. On client devices, we've replicated the issue using Chrome on Windows, and Chrome & Safari on Mac. For remote devices, this has happened on multiple Raspberry Pi devices, as well as an Intel NUC running Ubuntu 23.04. All types of remote devices we currently field have exhibited some sort of inconsistent hang-on-load issue in this manner. **Your config.json file** ``` { "$schema": "http://info.meshcentral.com/downloads/meshcentral-config-schema.json", "settings": { "cert": "mesh.$DOMAIN.com", "_WANonly": true, "_LANonly": true, "sessionKey": "$PASSWORD", "port": 443, "_aliasPort": 443, "redirPort": 80, "_redirAliasPort": 80, "RelayDNS": "relay.mesh.$DOMAIN.com", "AgentPong": 300, "TLSOffload": false, "trustedProxy": "$PROXY_IP,$ROUTER_IP", "SelfUpdate": false, "allowLoginToken": true, "allowFraming": true, "mongodb": "mongodb://mongodb:27017/mesh", "mongodbcol": "mesh", "WebRTC": true, "desktopMultiplex": true, "cookieIpCheck": "none", "sessionSameSite": "lax", "plugins": { "enabled": true } }, "domains": { "": { "title": "$COMPANY", "title2": "Internal Mesh", "_minify": true, "NewAccounts": "false", "_userNameIsEmail": true, "certUrl": "https://$PROXY_IP:443", "passwordRequirements": { "force2factor": true, "autofido2fa": true } } }, "_letsencrypt": { "__comment__": "Requires NodeJS 8.x or better, Go to https://letsdebug.net/ first before>", "_email": "myemail@mydomain.com", "_names": "myserver.mydomain.com", "production": false } } ```

deekerman

2026-02-20 09:31:04 -05:00

closed this issue
added the
bug

sponsor found
labels

deekerman commented

2026-02-20 09:31:06 -05:00

Author

Owner

@si458 commented on GitHub (Nov 10, 2024):

ive just setup a ubuntu 22.04 vm (with desktop)
installed meshagent,
setup node-red using snap, (3.1.0 its showing)
then accessed via the port 1880 using the web relay
no issues loading up
i dont no how to use it like but i could drag and drop stuff and click deploy without any issues too

edit: your screenshot shows its stuck on 'Loading plugins'
what plugins do you have enabled for node-red? as chances are one of those doesnt work correctly with the web relay

@si458 commented on GitHub (Nov 10, 2024): ive just setup a ubuntu 22.04 vm (with desktop) installed meshagent, setup node-red using snap, (3.1.0 its showing) then accessed via the port 1880 using the web relay no issues loading up i dont no how to use it like but i could drag and drop stuff and click deploy without any issues too edit: your screenshot shows its stuck on 'Loading plugins' what plugins do you have enabled for node-red? as chances are one of those doesnt work correctly with the web relay

deekerman commented

2026-02-20 09:31:06 -05:00

Author

Owner

@SecareLupus commented on GitHub (Nov 12, 2024):

Thanks for giving those a look for me. I'm not sure if it's relevant, but
the devices that we are using are raspberry pi 4s, we've had it occur while
running both arm 32 & 64 bit versions of the OS, and the intermittent
nature of the issue means that sometimes it's fine, and other times it
appears to hang indefinitely. The interruption always happens during the
project loading progress bar, if it makes it to the editor, it will work
without issue.

I can probably record a screen cap of the issue tomorrow as demonstration,
but the thing I find perplexing is that I can't find any errors firing
anywhere, just a silent hang that can only be fixed by refreshing the tab,
or deleting the web relay and reestablishing it.

On Sun, Nov 10, 2024, 1:50 PM Simon Smith @.***> wrote:

ive just setup a ubuntu 22.04 vm (with desktop)
installed meshagent,
setup node-red using snap, (3.1.0 its showing)
then accessed via the port 1880 using the web relay
no issues loading up
i dont no how to use it like but i could drag and drop stuff and click
deploy without any issues too

—
Reply to this email directly, view it on GitHub
https://github.com/Ylianst/MeshCentral/issues/6456#issuecomment-2466843987,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAZQBBACZR2ZROSI2PYX7ULZ76TGPAVCNFSM6AAAAABQCCES6SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRWHA2DGOJYG4
.
You are receiving this because you authored the thread.Message ID:
@.***>

@SecareLupus commented on GitHub (Nov 12, 2024): Thanks for giving those a look for me. I'm not sure if it's relevant, but the devices that we are using are raspberry pi 4s, we've had it occur while running both arm 32 & 64 bit versions of the OS, and the intermittent nature of the issue means that sometimes it's fine, and other times it appears to hang indefinitely. The interruption always happens during the project loading progress bar, if it makes it to the editor, it will work without issue. I can probably record a screen cap of the issue tomorrow as demonstration, but the thing I find perplexing is that I can't find any errors firing anywhere, just a silent hang that can only be fixed by refreshing the tab, or deleting the web relay and reestablishing it. On Sun, Nov 10, 2024, 1:50 PM Simon Smith ***@***.***> wrote: > ive just setup a ubuntu 22.04 vm (with desktop) > installed meshagent, > setup node-red using snap, (3.1.0 its showing) > then accessed via the port 1880 using the web relay > no issues loading up > i dont no how to use it like but i could drag and drop stuff and click > deploy without any issues too > > — > Reply to this email directly, view it on GitHub > <https://github.com/Ylianst/MeshCentral/issues/6456#issuecomment-2466843987>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAZQBBACZR2ZROSI2PYX7ULZ76TGPAVCNFSM6AAAAABQCCES6SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRWHA2DGOJYG4> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

deekerman commented

2026-02-20 09:31:06 -05:00

Author

Owner

@SecareLupus commented on GitHub (Nov 13, 2024):

Oh, as to the plugins, that's where it froze this time, but it's been known to hang at several stages, sometimes halfway through loading nodes. It's entirely possible that a particular plugin+node combo is at fault, I'm just not sure how to track it down, or why it's not an always issue. There don't appear to be errors logged anywhere I've been able to find. Just an open connection to the web server, presumably awaiting content hydration, but not timing out or completing.

For completeness, here's the list of nodered plugins our project currently uses:

node-red
node-red-*, where * ==
	*-contrib-cache
	*-contrib-config
	*-contrib-filebrowser
	*-contrib-fs
	*-contrib-fs-ops
	*-contrib-http-auth0
	*-contrib-httpauth
	*-contrib-loop-processing
	*-contrib-md5
	*-contrib-os
	*-contrib-particle
	*-contrib-play-audio
	*-contrib-render
	*-contrib-s3
	*-contrib-smb
	*-contrib-tcp-client
	*-contrib-uuid
	*-dashboard
	*-node-base64
	*-node-daemon
	*-node-ledborg
	*-node-mysql
	*-node-pi-gpio
	*-node-ping
	*-node-pusher
	*-node-random
	*-node-rbe
	*-node-serialport
	*-node-smooth
	*-node-tail
	*-node-ui-table

@SecareLupus commented on GitHub (Nov 13, 2024): Oh, as to the plugins, that's where it froze this time, but it's been known to hang at several stages, sometimes halfway through loading nodes. It's entirely possible that a particular plugin+node combo is at fault, I'm just not sure how to track it down, or why it's not an always issue. There don't appear to be errors logged anywhere I've been able to find. Just an open connection to the web server, presumably awaiting content hydration, but not timing out or completing. For completeness, here's the list of nodered plugins our project currently uses: ``` node-red node-red-*, where * == *-contrib-cache *-contrib-config *-contrib-filebrowser *-contrib-fs *-contrib-fs-ops *-contrib-http-auth0 *-contrib-httpauth *-contrib-loop-processing *-contrib-md5 *-contrib-os *-contrib-particle *-contrib-play-audio *-contrib-render *-contrib-s3 *-contrib-smb *-contrib-tcp-client *-contrib-uuid *-dashboard *-node-base64 *-node-daemon *-node-ledborg *-node-mysql *-node-pi-gpio *-node-ping *-node-pusher *-node-random *-node-rbe *-node-serialport *-node-smooth *-node-tail *-node-ui-table ```

deekerman commented

2026-02-20 09:31:06 -05:00

Author

Owner

@si458 commented on GitHub (Nov 14, 2024):

so. i installed all those plugins apart from contrib-filebrowser as it keps failing to install for some reason?

still cant get it to NOT load haha
but this is a 4 core, 8GB VM, not a raspberry pi,
so i might need to do more testing over weekend and get my Pi collection out the cupboard haha

@si458 commented on GitHub (Nov 14, 2024): so. i installed all those plugins apart from `contrib-filebrowser` as it keps failing to install for some reason? ![image](https://github.com/user-attachments/assets/34cfeb6d-c06a-4dc4-8b58-d4045cdd1e94) still cant get it to NOT load haha but this is a 4 core, 8GB VM, not a raspberry pi, so i might need to do more testing over weekend and get my Pi collection out the cupboard haha

deekerman commented

2026-02-20 09:31:06 -05:00

Author

Owner

@si458 commented on GitHub (Nov 14, 2024):

so ive just tested with a raspberry pi 3 i had spare doing nothing
and nope, still loads up fine, installed all plugins too (expect the filebrowser again),
so i have a feeling it might be the complex project.
have you tried wiping node-red and starting a fresh and seeing it it loads up a blank project without issues?

@si458 commented on GitHub (Nov 14, 2024): so ive just tested with a raspberry pi 3 i had spare doing nothing and nope, still loads up fine, installed all plugins too (expect the filebrowser again), so i have a feeling it might be the complex project. have you tried wiping node-red and starting a fresh and seeing it it loads up a blank project without issues?

deekerman commented

2026-02-20 09:31:06 -05:00

Author

Owner

@SecareLupus commented on GitHub (Nov 21, 2024):

(I typed this response via email last week, and didn't realize until now
that it was in my drafts folder)

My current working theory is an out-of-date version of node.js or node-red,
or possibly one of the dependencies. I will try to put refactoring and
dependency updating on my to-do list for the near future, see if that can
sort it out. I will also see if I can replicate the issue on a blank
project. I appreciate the effort you put into trying to recreate the issue.
If you wanted to resolve this as worksforme, I think that's totally
reasonable. I'm willing to conclude at this point that the issue is likely
in our project, and I can reopen the ticket if further data implies
otherwise.

On Thu, Nov 14, 2024, 9:10 AM Simon Smith @.***> wrote:

so ive just tested with a raspberry pi 3 i had spare doing nothing
and nope, still loads up fine, installed all plugins too (expect the
filebrowser again),
so i have a feeling it might be the complex project.
have you tried wiping node-red and starting a fresh and seeing it it loads
up a blank project without issues?

—
Reply to this email directly, view it on GitHub
https://github.com/Ylianst/MeshCentral/issues/6456#issuecomment-2476451586,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAZQBBHLDZKB3QNFKAOJSRT2ASVMZAVCNFSM6AAAAABQCCES6SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZWGQ2TCNJYGY
.
You are receiving this because you authored the thread.Message ID:
@.***>

@SecareLupus commented on GitHub (Nov 21, 2024): (I typed this response via email last week, and didn't realize until now that it was in my drafts folder) My current working theory is an out-of-date version of node.js or node-red, or possibly one of the dependencies. I will try to put refactoring and dependency updating on my to-do list for the near future, see if that can sort it out. I will also see if I can replicate the issue on a blank project. I appreciate the effort you put into trying to recreate the issue. If you wanted to resolve this as `worksforme`, I think that's totally reasonable. I'm willing to conclude at this point that the issue is likely in our project, and I can reopen the ticket if further data implies otherwise. On Thu, Nov 14, 2024, 9:10 AM Simon Smith ***@***.***> wrote: > so ive just tested with a raspberry pi 3 i had spare doing nothing > and nope, still loads up fine, installed all plugins too (expect the > filebrowser again), > so i have a feeling it might be the complex project. > have you tried wiping node-red and starting a fresh and seeing it it loads > up a blank project without issues? > > — > Reply to this email directly, view it on GitHub > <https://github.com/Ylianst/MeshCentral/issues/6456#issuecomment-2476451586>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAZQBBHLDZKB3QNFKAOJSRT2ASVMZAVCNFSM6AAAAABQCCES6SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZWGQ2TCNJYGY> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

deekerman commented

2026-02-20 09:31:06 -05:00

Author

Owner

@smithtekIOT commented on GitHub (Dec 2, 2024):

Hello Simon, I have emailed you directly to your published email on here, its regarding some help with MC.
Kind Regards
Dan Smith

@smithtekIOT commented on GitHub (Dec 2, 2024): Hello Simon, I have emailed you directly to your published email on here, its regarding some help with MC. Kind Regards Dan Smith

deekerman commented

2026-02-20 09:31:06 -05:00

Author

Owner

@SecareLupus commented on GitHub (Jan 9, 2025):

I noticed something interesting about this issue, which is that any time that it hangs, it does so immediately after a network request that seems to have the goal of switching from HTTP to Websocket for backend<->frontend communication.

curl 'wss://relay.mesh.COMPANYNAME.com/comms' \
  -H 'Upgrade: websocket' \
  -H 'Origin: https://relay.mesh.COMPANYNAME.com' \
  -H 'Cache-Control: no-cache' \
  -H 'Accept-Language: en-US,en;q=0.9,fr-CA;q=0.8,fr;q=0.7' \
  -H 'Pragma: no-cache' \
  -H 'Cookie: xid=XXXXXXXXXXX==; xid.sig=XXXXXXXXXXX' \
  -H 'Connection: Upgrade' \
  -H 'Sec-WebSocket-Key: XXXXXXXXXXXXXX==' \
  -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36' \
  -H 'Sec-WebSocket-Version: 13' \
  -H 'Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits'

{"auth":"XXXXXXXXXXXX="}

HTTP/1.1 101 Switching Protocols
Server: openresty
Date: Thu, 09 Jan 2025 18:29:04 GMT
Connection: upgrade
Upgrade: websocket
Sec-WebSocket-Accept: XXXXXXXXXXXX=

This request is followed by an XHR request that stalls at "pending" until it fails.

curl 'https://relay.mesh.COMPANYNAME.com/nodes/messages?lng=en-US&_=XXXXXXXXXX' \
  -H 'accept: application/json' \
  -H 'accept-language: en-US,en;q=0.9,fr-CA;q=0.8,fr;q=0.7' \
  -H 'authorization: Bearer XXXXXXXXXXXXXXXX=' \
  -H 'cache-control: no-cache' \
  -H 'cookie: xid=XXXXXXXXXXX==; xid.sig=XXXXXXXXXXXX' \
  -H 'node-red-api-version: v2' \
  -H 'pragma: no-cache' \
  -H 'priority: u=1, i' \
  -H 'referer: https://relay.mesh.COMPANYNAME.com/' \
  -H 'sec-ch-ua: "Google Chrome";v="131", "Chromium";v="131", "Not_A Brand";v="24"' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'sec-ch-ua-platform: "Linux"' \
  -H 'sec-fetch-dest: empty' \
  -H 'sec-fetch-mode: cors' \
  -H 'sec-fetch-site: same-origin' \
  -H 'user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36' \
  -H 'x-requested-with: XMLHttpRequest' \
  --insecure

When it eventually fails, it does so with a 504 Gateway Timeout

<html>
<head><title>504 Gateway Time-out</title></head>
<body>
<center><h1>504 Gateway Time-out</h1></center>
<hr><center>openresty</center>
</body>
</html>

@SecareLupus commented on GitHub (Jan 9, 2025): I noticed something interesting about this issue, which is that any time that it hangs, it does so immediately after a network request that seems to have the goal of switching from HTTP to Websocket for backend<->frontend communication. ```curl curl 'wss://relay.mesh.COMPANYNAME.com/comms' \ -H 'Upgrade: websocket' \ -H 'Origin: https://relay.mesh.COMPANYNAME.com' \ -H 'Cache-Control: no-cache' \ -H 'Accept-Language: en-US,en;q=0.9,fr-CA;q=0.8,fr;q=0.7' \ -H 'Pragma: no-cache' \ -H 'Cookie: xid=XXXXXXXXXXX==; xid.sig=XXXXXXXXXXX' \ -H 'Connection: Upgrade' \ -H 'Sec-WebSocket-Key: XXXXXXXXXXXXXX==' \ -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36' \ -H 'Sec-WebSocket-Version: 13' \ -H 'Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits' ``` ```Messages {"auth":"XXXXXXXXXXXX="} ``` ```Response Headers HTTP/1.1 101 Switching Protocols Server: openresty Date: Thu, 09 Jan 2025 18:29:04 GMT Connection: upgrade Upgrade: websocket Sec-WebSocket-Accept: XXXXXXXXXXXX= ``` This request is followed by an XHR request that stalls at "pending" until it fails. ```curl curl 'https://relay.mesh.COMPANYNAME.com/nodes/messages?lng=en-US&_=XXXXXXXXXX' \ -H 'accept: application/json' \ -H 'accept-language: en-US,en;q=0.9,fr-CA;q=0.8,fr;q=0.7' \ -H 'authorization: Bearer XXXXXXXXXXXXXXXX=' \ -H 'cache-control: no-cache' \ -H 'cookie: xid=XXXXXXXXXXX==; xid.sig=XXXXXXXXXXXX' \ -H 'node-red-api-version: v2' \ -H 'pragma: no-cache' \ -H 'priority: u=1, i' \ -H 'referer: https://relay.mesh.COMPANYNAME.com/' \ -H 'sec-ch-ua: "Google Chrome";v="131", "Chromium";v="131", "Not_A Brand";v="24"' \ -H 'sec-ch-ua-mobile: ?0' \ -H 'sec-ch-ua-platform: "Linux"' \ -H 'sec-fetch-dest: empty' \ -H 'sec-fetch-mode: cors' \ -H 'sec-fetch-site: same-origin' \ -H 'user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36' \ -H 'x-requested-with: XMLHttpRequest' \ --insecure ``` When it eventually fails, it does so with a 504 Gateway Timeout ```response <html> <head><title>504 Gateway Time-out</title></head> <body> <center><h1>504 Gateway Time-out</h1></center> <hr><center>openresty</center> </body> </html> ```

deekerman commented

2026-02-20 09:31:06 -05:00

Author

Owner

@si458 commented on GitHub (Feb 5, 2025):

@SecareLupus i believe this commit might fix your issue possible github.com/Ylianst/MeshCentral@c96d7ff1ca

@smithtekIOT i also believe this commit will fix the node-red web ui not loading resources correctly from external websites

@si458 commented on GitHub (Feb 5, 2025): @SecareLupus i believe this commit might fix your issue possible https://github.com/Ylianst/MeshCentral/commit/c96d7ff1caaf184868e24ac9c256a9cc562ac643 @smithtekIOT i also believe this commit will fix the node-red web ui not loading resources correctly from external websites

deekerman commented

2026-02-20 09:31:06 -05:00

Author

Owner

@SecareLupus commented on GitHub (Feb 7, 2025):

I manually commented out apprelays.js:722 as in the commit referenced, and while I had trouble getting it to trigger the first time, it does seem to still occur following the same pattern as my previous message, with one exception.

After several minutes, the browser started sending repeated calls to comms with the {"auth":"XXXX"} value, none of them hanging, but terminating without response (other than "101 Switching Protocols") quickly.

~~It's possible the repeated comms calls happened before, but this is the first time I've noticed them.~~

Edit: I did not restart Meshcentral and so my results were not representative of a modified apprelays.js file. I will test again when the server can be safely restarted and update.

@SecareLupus commented on GitHub (Feb 7, 2025): ~~I manually commented out `apprelays.js:722` as in the commit referenced, and while I had trouble getting it to trigger the first time, it does seem to still occur following the same pattern as my previous message, with one exception.~~ ~~After several minutes, the browser started sending repeated calls to comms with the {"auth":"XXXX"} value, none of them hanging, but terminating without response (other than "101 Switching Protocols") quickly.~~ ~~It's possible the repeated comms calls happened before, but this is the first time I've noticed them.~~ Edit: I did not restart Meshcentral and so my results were not representative of a modified `apprelays.js` file. I will test again when the server can be safely restarted and update.

deekerman commented

2026-02-20 09:31:06 -05:00

Author

Owner

@si458 commented on GitHub (Feb 7, 2025):

@SecareLupus IF its possible can u email myself?
i would like to put my development meshagent on the pc having the issue and see what happens from here

@si458 commented on GitHub (Feb 7, 2025): @SecareLupus IF its possible can u email myself? i would like to put my development meshagent on the pc having the issue and see what happens from here

deekerman commented

2026-02-20 09:31:06 -05:00

Author

Owner

@SecareLupus commented on GitHub (Feb 20, 2025):

@si458, The change may have fixed the issue with two caveats.

Because the issue is intermittent, I can't be sure whether it's working until it doesn't work. Up until now, I have not been able to trigger the issue though.
While I have been able to get NodeRed to load every attempt since the change was implemented, it does sometimes hang until I open Chrome DevTools. As soon as DevTools is open, any apparent hang completes... Would it have completed anyway? I can't say for sure, but this was a repeatable experience... No idea how opening DevTools could affect the loading process of a page, though.

I'm willing to tentatively assume this is fixed, as I said, I've not been able to get any instance to refuse to load since making the change (after opening devtools). If you're interested in access by attaching one of our fleet devices to your server, or sharing access to our server, that can definitely be arranged, but I'm not sure whether it's necessary at this point.

@SecareLupus commented on GitHub (Feb 20, 2025): @si458, The change may have fixed the issue with two caveats. * Because the issue is intermittent, I can't be _sure_ whether it's working until it doesn't work. Up until now, I have not been able to trigger the issue though. * While I have been able to get NodeRed to load every attempt since the change was implemented, it does sometimes hang until I open Chrome DevTools. As soon as DevTools is open, any apparent hang completes... Would it have completed anyway? I can't say for sure, but this was a repeatable experience... No idea how opening DevTools could affect the loading process of a page, though. I'm willing to tentatively assume this is fixed, as I said, I've not been able to get any instance to refuse to load since making the change (after opening devtools). If you're interested in access by attaching one of our fleet devices to your server, or sharing access to our server, that can definitely be arranged, but I'm not sure whether it's necessary at this point.

deekerman commented

2026-02-20 09:31:06 -05:00

Author

Owner

@si458 commented on GitHub (Feb 20, 2025):

@SecareLupus so it works but then stops and when it stops you open the devtools and then it works again?
thats bloody weird indeed?

@si458 commented on GitHub (Feb 20, 2025): @SecareLupus so it works but then stops and when it stops you open the devtools and then it works again? thats bloody weird indeed?

deekerman commented

2026-02-20 09:31:06 -05:00

Author

Owner

@SecareLupus commented on GitHub (Feb 20, 2025):

Right? Like, maybe it would've completed anyway, but more than once I've tried to wait, only to give up and have it complete right after pulling open the network pane to investigate what's going on... v strange, but it seems functional to a point that probably isn't a bug on your end... I've also only tested this in Chrome, so more investigation is needed on my end before I conclude anything else.

@SecareLupus commented on GitHub (Feb 20, 2025): Right? Like, maybe it would've completed anyway, but more than once I've tried to wait, only to give up and have it complete _right_ after pulling open the network pane to investigate what's going on... v strange, but it seems functional to a point that probably isn't a bug on your end... I've also only tested this in Chrome, so more investigation is needed on my end before I conclude anything else.

deekerman commented

2026-02-20 09:31:06 -05:00

Author

Owner

@si458 commented on GitHub (Feb 20, 2025):

one thing you could try is clicking the relay, then when the web page opens, about 1-2 sec after click the STOP button quickly!
then open up devtools, into network tab, then refresh the webpage (F5)
then watch the network tab and see what happens?
(the cookie will be stored so the relay should still happen)

@si458 commented on GitHub (Feb 20, 2025): one thing you could try is clicking the relay, then when the web page opens, about 1-2 sec after click the STOP button quickly! then open up devtools, into network tab, then refresh the webpage (F5) then watch the network tab and see what happens? (the cookie will be stored so the relay should still happen)

deekerman commented

2026-02-20 09:31:06 -05:00

Author

Owner

@si458 commented on GitHub (Jun 21, 2025):

i believe this issue MIGHT be fixed by this commit! github.com/Ylianst/MeshCentral@92c2b61318
basically all web relay connections where getting gzip compressed
so ive disabled it now by default and if u enable it, then its disabled for web relaying
it actually fixed my event-stream issue from months ago!

edit: also maybe this fix too? github.com/Ylianst/MeshCentral@cadc0d03d2
where it didnt create new tunnels for the webrelay correctly!

edit2: more bug fixes may fix this issue too? github.com/Ylianst/MeshCentral@95759d4022
this was a timeout bug where the sessions for webrelay where timing out after 1 min instead of the default 5 mins!

@si458 commented on GitHub (Jun 21, 2025): i believe this issue MIGHT be fixed by this commit! https://github.com/Ylianst/MeshCentral/commit/92c2b613185cf21ca5745f182b56a50c365957c4 basically all web relay connections where getting gzip compressed so ive disabled it now by default and if u enable it, then its disabled for web relaying it actually fixed my event-stream issue from months ago! edit: also maybe this fix too? https://github.com/Ylianst/MeshCentral/commit/cadc0d03d287c297ccf6513d3ab16435eb27fd18 where it didnt create new tunnels for the webrelay correctly! edit2: more bug fixes may fix this issue too? https://github.com/Ylianst/MeshCentral/commit/95759d40221415d034babcfd04792c1a556f1a2e this was a timeout bug where the sessions for webrelay where timing out after 1 min instead of the default 5 mins!

deekerman commented

2026-02-20 09:31:06 -05:00

Author

Owner

@SecareLupus commented on GitHub (Jun 21, 2025):

@si458, That's awesome, I can't wait to test it out. If I have time, I'll snapshot our instance so I can apply the commits manually and try them out. Otherwise, I'll keep an eye on the point release commit logs. I think we're still running .43 at the moment, so we have a couple updates to push. Is it likely these will be in .46?

@SecareLupus commented on GitHub (Jun 21, 2025): @si458, That's awesome, I can't wait to test it out. If I have time, I'll snapshot our instance so I can apply the commits manually and try them out. Otherwise, I'll keep an eye on the point release commit logs. I think we're still running .43 at the moment, so we have a couple updates to push. Is it likely these will be in .46?

deekerman commented

2026-02-20 09:31:06 -05:00

Author

Owner

@si458 commented on GitHub (Jun 21, 2025):

@SecareLupus yes it will be in the next release (due this week before our monthly meeting on thursday!)
but yes i would say try applying those 3 commits i mensioned above and see what happens!
fingers n toes!

P.S: i also discovered the double login issue with node-red u mensioned last time
i think this is something to do with node-red and not meshcentral
but havent been able to fix that yet

@si458 commented on GitHub (Jun 21, 2025): @SecareLupus yes it will be in the next release (due this week before our monthly meeting on thursday!) but yes i would say try applying those 3 commits i mensioned above and see what happens! fingers n toes! P.S: i also discovered the double login issue with node-red u mensioned last time i think this is something to do with node-red and not meshcentral but havent been able to fix that yet

deekerman commented

2026-02-20 09:31:06 -05:00

Author

Owner

@si458 commented on GitHub (Jul 22, 2025):

@SecareLupus did you ever verify if this has been fixed at all or still an issue?
i dont seem to have problems anymore (apart from a weird double login bug with node-red)

@si458 commented on GitHub (Jul 22, 2025): @SecareLupus did you ever verify if this has been fixed at all or still an issue? i dont seem to have problems anymore (apart from a weird double login bug with node-red)

deekerman commented

2026-02-20 09:31:06 -05:00

Author

Owner

@SecareLupus commented on GitHub (Jul 22, 2025):

I'm unfortunately still stuck on .44 because of the weird issue with my remote desktop display going black at >= .46, I'm following up on that ticket now.

I can reliably get to the nodered flows at this point (by opening devtools), which was the biggest thing. I think there's a good chance that the three commits you referenced earlier, targeted for .46 could also have an effect. I'm not against closing the ticket at this point. I can always re-open it if I can find anything verifiable once I get back onto the update track.

@SecareLupus commented on GitHub (Jul 22, 2025): I'm unfortunately still stuck on .44 because of the weird issue with my remote desktop display going black at >= .46, I'm following up on that ticket now. I can reliably get to the nodered flows at this point (by opening devtools), which was the biggest thing. I think there's a good chance that the three commits you referenced earlier, targeted for .46 could also have an effect. I'm not against closing the ticket at this point. I can always re-open it if I can find anything verifiable once I get back onto the update track.

deekerman commented

2026-02-20 09:31:06 -05:00

Author

Owner

@SecareLupus commented on GitHub (Jul 22, 2025):

Alright, so I made it to .47, and the first test in nodered required double login, but did not require devtools. That's not confirmation that the issue is gone, but it's a really good sign. I maintain my previous sentiment that this ticket can probably be closed, I consider the current state more than usable (especially if the test I just did is not a fluke).

@SecareLupus commented on GitHub (Jul 22, 2025): Alright, so I made it to .47, and the first test in nodered required double login, but did not require devtools. That's not confirmation that the issue is gone, but it's a really good sign. I maintain my previous sentiment that this ticket can probably be closed, I consider the current state more than usable (especially if the test I just did is not a fluke).

deekerman commented

2026-02-20 09:31:06 -05:00

Author

Owner

@si458 commented on GitHub (Jul 22, 2025):

yeh ive still to work out WHY node-red needs double logging in?
ive debugged it and i can see we request to node-red for auth, it auths and gives us info for token etc
then when we load up the next page, node-red as suddenly like forgotten the information i just gave it!
so im not sure if its a cookie issue maybe or something else,
i would say open another issue for that as thats different to the 'hanging and not loading' issue

@si458 commented on GitHub (Jul 22, 2025): yeh ive still to work out WHY node-red needs double logging in? ive debugged it and i can see we request to node-red for auth, it auths and gives us info for token etc then when we load up the next page, node-red as suddenly like forgotten the information i just gave it! so im not sure if its a cookie issue maybe or something else, i would say open another issue for that as thats different to the 'hanging and not loading' issue

Rows
Columns

Node-Red Editor Sometimes Hangs on Load over Webrelay #4951