Ignition Cloud MQTT Broker: Which Host URL Does Node-RED Use?

Which address does the MQTT Distributor answer on?

Use the same public IP address or DNS name you already use to reach the gateway web page. The MQTT Distributor module runs inside the Ignition gateway process, so it listens on the gateway host's own network interfaces. The difference is the port. The gateway web UI answers on 80/443. The broker answers on the MQTT ports: 1883 for plain MQTT and 8883 for MQTT over TLS (MQTTS).

When Node-RED times out against the gateway IP, the address is usually correct. The packet is being dropped before it reaches the Distributor. On Ignition Cloud Edition, the cloud security group only allows 80/443 inbound by default. A connection attempt to 1883 or 8883 dies at the cloud network edge and never reaches the VM.

Where does the Node-RED packet stop?

Follow the packet from Node-RED to the Distributor listener. Each hop can drop it, and every drop looks the same from the client side: a connect timeout or "connection refused".

Settle one ambiguity before troubleshooting. The setup was described both as "Ignition Cloud" and as a gateway hosted on a local PC reached over the internet. Those are two different edge devices. Cloud Edition runs on an AWS or Azure VM, where the security group is the gate. A self-hosted gateway on an office PC sits behind a router, where a NAT port forward is the gate. Identify which one owns the public IP you type into the browser. Then work on that device.

Plain 1883 or TLS on 8883?

Recommendation: publish over 8883 with TLS. Use 1883 only for a first connectivity test, and restrict its inbound rule to the Node-RED host's public IP. Once the gateway web server has a certificate, the Distributor presents that same certificate on 8883. No separate broker certificate needs to be managed.

How do you open the path and configure Node-RED?

1. In the cloud console, open the security group attached to the Ignition VM. In AWS this is the EC2 Security Group. In Azure it is the Network Security Group.
2. Add an inbound rule for TCP 8883. Add TCP 1883 only if you need the plain test. Set the source to the Node-RED site's public IP rather than 0.0.0.0/0 wherever the site has a fixed address.
3. If the gateway is self-hosted instead of cloud-hosted, add the same ports as a port forward on the edge router, pointing at the gateway PC's LAN IP. Then add matching inbound rules in the PC's OS firewall.
4. Install a TLS certificate on the gateway web server, issued for the DNS name clients will use. Point a DNS record at the gateway's public IP if you do not already have one.
5. In the gateway, confirm the MQTT Distributor module is running and that the user you created is listed under the Distributor's user configuration. Distributor users are separate from gateway login users.
6. In Node-RED, open the mqtt-broker config node. Set Server to the gateway DNS name with no scheme prefix. Set Port to 8883 and tick Use TLS. Under Security, enter the Distributor username and password.
7. If the certificate is from a public CA, keep server certificate verification enabled. If it is self-signed, load its CA into the Node-RED TLS config rather than disabling verification.
8. Deploy. Watch the status indicator under the MQTT node.

What trips engineers up on this setup?

• TLS by raw IP. The certificate is issued to a hostname. A client connecting to 8883 by IP fails hostname verification even though TCP connects. Use the DNS name.
• Scheme in the Node-RED Server field. Node-RED takes the host and port separately. Entering mqtt:// or tcp:// with the host, plus a port in another field, produces a malformed target.
• Opening the wrong firewall. An open OS firewall does nothing if the cloud security group still allows only 80/443. Layer one first, then the edge, then the host.
• Expecting tags from arbitrary JSON. MQTT Transmission and MQTT Engine are Sparkplug B clients. A plain JSON payload from Node-RED reaches the Distributor fine. However, MQTT Engine only turns it into tags if the payload is Sparkplug B encoded or an Engine custom namespace is configured for that topic.
• Distributor versus Engine credentials. Node-RED authenticates against the Distributor's user list. The Engine and Transmission connections inside the gateway have their own server definitions and do not grant access to external clients.

How do you verify the broker is reachable end to end?

1. From the Node-RED host, test TCP reachability. On Windows run Test-NetConnection <gateway-dns> -Port 8883 and confirm TcpTestSucceeded : True. On Linux, nc -vz <gateway-dns> 8883 should report success. A failure here means hops 1-4. Revisit the security group, router, or OS firewall.
2. On the gateway host, confirm the listener with netstat -an and look for 8883 (and 1883 if enabled) in LISTEN state. If it is absent, the Distributor module or its listener configuration is the fault, not the network.
3. Check the TLS handshake with openssl s_client -connect <gateway-dns>:8883. The presented certificate should be the gateway web server certificate, and its subject/SAN should match the name you used.
4. In Node-RED, confirm the MQTT node shows connected. Wire an mqtt in node subscribed to a test topic and an mqtt out node publishing to the same topic. The injected message should come back through the Distributor.
5. If the goal is Ignition tags, publish a Sparkplug B payload or a topic covered by an Engine custom namespace. Confirm the tags appear under the MQTT Engine tag provider in the Designer tag browser.

FAQ