Troubleshooting

Common problems connecting Mirth to Synura and how to fix them.

---

Connection refused on localhost:6661

Symptom: Mirth Server Log shows java.net.ConnectException: Connection refused: connect every poll cycle.

Cause: stunnel is not running, or is not configured to listen on port 6661.

Fix:

1. Check if stunnel is running:

   # Windows
   Get-Service stunnel

   # Linux
   systemctl status stunnel4

2. If stunnel is stopped, start it:

   # Windows
   Start-Service stunnel

   # Linux
   sudo systemctl start stunnel4

3. On Windows Server 2016, the stunnel service may not auto-start after installation. Set it to start automatically:

   Set-Service stunnel -StartupType Automatic

4. Verify the listener:

   # Windows
   netstat -an | findstr 6661

   You should see LISTENING on 127.0.0.1:6661.

---

TLS handshake failed

Symptom: stunnel connects but the TLS handshake fails. In stunnel logs: SSL_connect: error or tlsv1 alert internal error.

Cause: One of:

• The stunnel configuration points to the wrong hostname
• SNI is not being sent correctly
• A network appliance is intercepting TLS traffic

Fix:

1. Enable stunnel debug logging. Add these lines to the top of your stunnel configuration file:

   output = C:\stunnel.log
   debug = 7

   Restart stunnel. Wait for a poll cycle. Check C:\stunnel.log for detail.

2. Verify the configuration file has the correct subdomain:

   [synura]
   client = yes
   accept = 127.0.0.1:6661
   connect = {subdomain}.synura.io:443

3. Test the TLS connection independently:

   openssl s_client -connect {subdomain}.synura.io:443 -servername {subdomain}.synura.io

   You should see CN=*.synura.io in the certificate. If you see a different certificate (e.g. your corporate proxy), your network is intercepting TLS — speak to your IT team.

---

Connection timeout

Symptom: Connection hangs and eventually times out. Network test also times out.

Cause: A firewall or network policy is blocking outbound TCP 443 to synura.io.

Fix:

1. Test connectivity from the Mirth server:

   Test-NetConnection {subdomain}.synura.io -Port 443

2. If TcpTestSucceeded is False, outbound port 443 is blocked. Ask your network team to allow outbound TCP 443 from the Mirth server to synura.io.

3. Note that Synura Connect uses MLLP over TLS, which is not HTTP. It cannot pass through a standard HTTP proxy. If your organisation routes all traffic through an HTTP proxy, the Synura Connect connection must bypass it or use a TCP-level proxy (SOCKS or transparent TCP).

---

Channel polling but no messages appearing

Symptom: The channel is Started and polling (you can see it in the Connection Log moving between Reading and Idle), but the Received count stays at 0.

Cause: One of:

• The mailbox is empty — no messages have been queued for your endpoint
• The sending facility code in the channel does not match the endpoint configuration in Synura
• The channel script has a silent parsing error

Fix:

1. Check the Mirth Server Log for any entries starting with Synura poll:. If you see Synura poll: received MAILBOX^..., messages are being received but may be filtered or errored downstream.

2. If the Server Log is completely silent (no Synura poll entries at all), the script may be failing silently. Add temporary debug logging — change the first line after socket.close() to:

   var response = '' + buffer.toString('UTF-8');
   logger.info('DEBUG: response length=' + response.length);

   Redeploy and check the Server Log.

3. Verify your sending facility code matches what is registered in the Synura dashboard. The code in the channel’s CONFIG.sendingFacility must exactly match the endpoint’s sending facility in Synura.

4. Ask Synura support to queue a test message to your endpoint, or use the Synura dashboard to confirm messages are waiting.

---

Mirth Administrator does not launch

Symptom: Double-clicking the Mirth Connect Administrator shortcut or mcmanager.exe does nothing.

Cause: The Mirth Administrator requires Java Web Start (javaws), which is only included in Oracle JDK 8. OpenJDK and Corretto do not include it.

Fix:

1. Install Oracle JDK 8 if you haven’t already.

2. On Windows Server 2016, the Mirth Administrator may not install automatically during Mirth setup. Check if the launcher exists:

   ls "C:\Program Files\Mirth Connect\public_html\installers\*administrator*"

   If the file mirth-administrator-launcher-1.1.0-windows-x64.exe is present, run it to install the Administrator.

3. For Mirth 4.x, the Administrator is a standalone application and does not require Java Web Start.

---

NullPointerException in Server Log

Symptom: Server Log shows java.lang.NullPointerException: null after the channel processes messages.

Cause: The channel script is passing null to $gc() (Mirth’s global channel map). Mirth 3.8.1 does not accept null values.

Fix:

Check the channel JavaScript for any lines like:

$gc('synura_cursor', null);

Replace with:

$gc('synura_cursor', '');

This applies to all $gc calls — always use empty string, never null.

---

Messages received but count seems wrong

Symptom: You queued 3 messages but only see 1 or 2 in the Received count.

Cause: The channel requests one message per poll cycle. Multiple messages are drained across consecutive polls using continuation tokens (DSC segments). If the poll interval is 5 minutes, 3 messages take 15 minutes to fully drain.

This is normal behaviour. The channel will continue polling until all messages are delivered.

To drain faster, reduce the poll interval in the channel’s Source settings (e.g. to 15000ms / 15 seconds). At 5-second polling, the channel can drain 720+ messages per hour.

---

Support

If your issue is not listed here, contact support@synura.io with:

• Your Synura subdomain
• Mirth version number
• The last 50 lines of the Mirth Server Log
• stunnel log output (if available — see TLS handshake section for how to enable logging)