Mirth Connect MLLP Connection Issues: Connection Refused, Reset, and Timeouts

MLLP (Minimal Lower Layer Protocol) wraps each HL7 message between a start block (0x0B) and an end block (0x1C followed by 0x0D). If the sender or receiver doesn't agree on this framing, messages either never parse or hang waiting for an end byte that never arrives. Many "MLLP not working" cases are actually framing mismatches, not network failures.

A "connection refused" means nothing is listening on that host/port. Check, in order:

1. Is the channel deployed and the MLLP listener started? A common cause is simply a stopped channel.
2. Right host and port?Confirm the receiving channel's listener port matches what the sender targets.
3. Firewall / security group. Verify the port is open between the two hosts. Test from the sending host: a port check that fails confirms a network/firewall block, not a Mirth problem.
4. Binding address. If Mirth is bound to a specific interface (not 0.0.0.0), it won't accept connections on other interfaces.

A reset usually means the connection was established but then terminated — by Mirth, the peer, or something in between:

1. Framing mismatch.If the sender doesn't send proper MLLP start/end blocks, Mirth may reset or hang. Confirm both sides use standard MLLP framing.
2. Idle timeout.Long-lived connections can be dropped by a firewall or load balancer idle timeout. Check the connector's keep-alive and timeout settings against the network's.
3. ACK not returned (or not expected).If the sender waits for an HL7 ACK and Mirth's response settings don't send one (or send it on the wrong queue/response setting), the sender times out and drops. Verify the destination's response/ACK configuration.
4. TLS mismatch.If one side expects TLS and the other doesn't, the handshake fails and the connection resets. See Mirth Connect SSL/TLS hardening.

• The receiver is up but slow to ACK — check downstream processing time and thread availability.
• A proxy/load balancer between systems is buffering or breaking the raw TCP stream MLLP needs. MLLP is not HTTP; it should pass through as raw TCP.

1. Confirm the channel and MLLP listener are started.
2. From the sending host, test the port. Refused = network/firewall or stopped listener.
3. If connected but failing, capture the raw bytes and confirm MLLP start/end framing on both sides.
4. Check ACK/response configuration so the sender gets the acknowledgment it expects.
5. Align idle timeouts and keep-alive between Mirth, firewalls, and load balancers.
6. If TLS is involved, verify both sides agree on encryption and trust the certificates.

Document the agreed framing, port, and ACK expectations for each MLLP interface; monitor listener uptime and connection error rates; and avoid placing HTTP-aware proxies in the MLLP path. Continuous monitoring of listener health is part of managed support. For protocol fundamentals, see our HL7 integration guide.