SMPP bind failing after an IP change? Here's what's going on

Messages stop going out. The gateway logs show the bind failing, or the connection closing a second after it opens. Nothing changed in the config. Except, it turns out, the server's IP address.

Last updated 29 October 2026 · 4 min read

When an SMPP bind fails right after you moved servers, rebuilt an instance or had your connection renumbered, the IP is the first suspect. Many SMS providers only accept SMPP connections from addresses you've registered with them, and a connection from anywhere else is refused before your system ID and password are even checked. The fix is to get the new address registered, and then stop it changing. A static IP for SMPP is one way to do the second part. Here's how to confirm the cause first.

Why SMS providers lock SMPP to an IP

SMPP is a long-lived TCP connection between your gateway and the provider's SMSC. It carries a lot of traffic, so providers like to know exactly where it comes from.

Twilio says its SMPP service only accepts connections from a specific, predetermined set of IP addresses. Sinch's SMPP connectivity docs say access is restricted to pre-registered IPs by default. Infobip asks for the list of source IPs to safelist. With most providers, adding an address means a support ticket, not a dashboard edit, so a surprise IP change can mean hours of queued messages.

How to tell it's the IP and not the credentials

A few checks, from the machine that runs the gateway.

1. What address are you connecting from?

curl -4 https://ifconfig.co

Compare it with the address your provider has on file. If you don't know which one that is, it's in your onboarding email or ticket. Most of the time this is the answer.

2. Can you reach the SMSC port at all?

nc -vz smsc.example.com 2775

Use your provider's host and port. 2775 is the standard SMPP port, but many providers use others. If the connection is refused or times out here, it never got as far as a bind. That points to IP filtering or a firewall, not your password.

3. Does the bind fail immediately, every time?

Wrong credentials usually get you a proper bind response with an error in it. A connection that is closed straight away, with no response at all, is more typical of the source address being refused. Check your gateway's debug log to see which one you're getting.

4. Did anything change on the network side?

New server, new cloud instance, failover to a standby, a move to containers, a new office line. Any of these can change the outbound address even when the gateway config is identical.

Fixing it today

Send the new address to your provider's support and ask them to add it to your SMPP account. Mention the system ID, and ask whether the old address should stay or go. While you wait, if the old server still exists, point traffic back at it.

Stopping it from happening again

The lasting fix is to make sure your SMPP connection always leaves from one address you control, wherever the gateway runs.

A fixed IP on the server

If the gateway lives on one server for good, give that server a fixed public IP and register it. Plan for the standby too, because failover is when this usually bites.

A dedicated static IP with a local tunnel

This is the setup TrueIP supports. You get a dedicated IPv4 in Mumbai with a proxy login, and register that address with your provider. Most SMPP libraries can't use an HTTP proxy themselves, so you run a small local tunnel that opens the connection through TrueIP, and point the gateway at it:

socat TCP-LISTEN:2775,bind=127.0.0.1,fork,reuseaddr \
  PROXY:HOST:smsc.example.com:2775,proxyport=PORT,proxyauth=USER:PASS

Your SMPP client connects to 127.0.0.1:2775, and the SMSC sees your TrueIP address. Move the gateway to a new server and start the same tunnel there. Nothing to re-register. If your provider uses SMPP over TLS, keep using it, and set the TLS server name to the SMSC's hostname in your client, since it's now connecting to localhost.

A note on scope: this works for SMPP because it's a TCP connection you open. It does not work for SIP voice trunks, which need UDP and incoming calls. TrueIP doesn't carry either.

Running more than one SMS provider

Plenty of senders keep a second provider for failover or for different routes. Each one keeps its own allowlist, so a new address means a ticket with each of them, and it's easy to update one and forget the other until the day you fail over.

With one fixed address for all SMPP traffic, you register the same IP with every provider once. With the tunnel setup above, run one tunnel per SMSC on different local ports, for example 127.0.0.1:2775 for the main provider and 127.0.0.1:2776 for the backup, and point each SMPP account in your gateway at its own port.

Make the gateway handle drops well

Whatever the cause, a gateway that copes with drops loses fewer messages.

• Send enquire_link regularly so dead connections are noticed quickly.
• Reconnect and rebind automatically, with a growing delay between attempts.
• Alert someone after a few failed binds in a row, instead of letting the queue grow silently.
• Log the remote address and port on every connect attempt. It makes the next IP problem a two-minute fix.

Quick checklist

• Run curl -4 https://ifconfig.co on the gateway and compare it with the address your provider has.
• Test the port with nc -vz to see whether the connection is being refused.
• Ask the provider to register the new address, and remove the old one if it's gone for good.
• Register your standby or failover address too.
• Keep one address for good: a fixed server IP, or a static IP for SMPP with a local tunnel.

Keep reading