sslip.io local wildcard install: instance editor fails (Invalid WebSocket frame: RSV1 must be clear)

[dgatti0213]

Current Behavior

When running self-hosted FlowFuse using the documented sslip.io wildcard domain option (no local DNS server), opening a hosted instance editor causes repeated websocket errors and the editor does not load/work correctly.

Ideally I need an answer within a week on this. This method is in our docs:
https://flowfuse.com/docs/install/dns-setup/#no-local-dns-server

Expected Behavior

[warn] Communication channel error: RangeError: Invalid WebSocket frame: RSV1 must be clear
Editor fails to function correctly.

Steps To Reproduce

1.	Deploy FlowFuse via Docker Compose
2.	Configure domain using 127.0.0.1.sslip.io (per docs “No local DNS server”)
3.	Create/start a hosted instance
4.	Open the instance editor

Environment

• FlowFuse: v2.26.2
• Docker Desktop (macOS)
• sslip.io wildcard domain setup

Have you provided an initial effort estimate for this issue?

I have provided an initial effort estimate

[hardillb]

You can NOT use 127.0.0.1 you must use the docker host machines real IP address (or at an absolute minimum the IP address of the host side of the docker bridge interface)

This is because 127.0.0.1 always resolve to the internal loopback interface of each container so traffic can NEVER leave the container.

[dgatti0213]

issue persistes with the usage of: 192.168.50.233.sslip.io

Hosted url: http://combative-turtle-dove-5833.192.168.50.233.sslip.io/?#flow/cc9dc0f2adf0d457
Error: Communication channel error: RangeError: Invalid WebSocket frame: RSV1 must be clear

[hardillb]

Going to need a lot more context in the actual issue (not just a fathom video)

List all the interfaces and their IP addresses

Also give a better description of the actual failure case, e.g. does the editor open but then show a problem with WebSockets?

Is 192.168.50.233 the IP address of the whole machine or the docker interface? I'm guessing the host machine. What firewall is running?

Also any existing instances need to be totally removed if the domain entry is changed, they won't be updated.

[dgatti0213]

I spun up their compose file on my laptop to recreate the issue and experienced the same.
IP is the address of the host. Instance was spun up after deployment.

docker-compose.yml

env file example:
DOMAIN=192.168.50.233.sslip.io

POSTGRES_ROOT_USER=root
POSTGRES_ROOT_PASSWORD=password

FORGE_DB_USER=forge
FORGE_DB_PASSWORD=password

[dgatti0213]

Additional context:

This setup was also spun up on a Windows laptop on the same LAN and exhibits the exact same issue, so it does not seem to be macOS-specific.

Interfaces/IPs on host (macOS):

• en0: 192.168.50.233
• bridge100: 10.211.55.2
• bridge101: 10.37.129.2
  (loopback 127.0.0.1)

Firewall:

• macOS Application Firewall disabled (State = 0)
• Windows host also tested with no additional firewall rules blocking port 80

Host vs docker:

• 192.168.50.233 is the host (en0), not a docker interface.

[hardillb]

I still need a proper description of the failure. e.g. where EXACTLY the error message about WebSockets is show and under what circumstances.

Assumptions

1. you have created a new instance
2. How did you open the editor (the Open Editor button or the link to the editor, These do VERY different things so I need to know which one you clicked on)
3. I assume the error is in the browser developer tools?
4. Which browser you are using (do not use Safari)

[dgatti0213]

Failure description (WebSocket-related):

Environment:

• Browser: Chrome (not Safari)
• Editor opened via:
  • “Open Editor” button in the FlowFuse UI
  • Direct editor URL
    (Both methods exhibit identical behaviour)

Assumptions:

• A new instance was created after setting DOMAIN
• Instance was fully started and healthy

Observed behaviour:

• The Node-RED editor UI loads successfully.
• Palette nodes can be dragged onto the canvas.
• Flows can be deployed successfully.
• Node-RED runtime is running.

What does NOT work:

• Inject nodes do not fire when clicked.
• Debug sidebar does not receive messages.
• No runtime interaction occurs from the editor UI.

Where errors are visible:

• Browser: Chrome Developer Tools
  • Console and Network tabs show WebSocket-related errors.
• Node-RED instance logs:
  • Corresponding WebSocket-related errors are also present in the Node-RED runtime logs when interaction is attempted.

Summary:

• HTTP-based editor functionality works (UI load, deploy).
• WebSocket communication between the editor and the Node-RED runtime fails.
• This affects inject/debug/runtime interaction.
• Behaviour is identical whether opening the editor via the “Open Editor” button or via the direct editor URL.