Twilio error 53000 means the signaling WebSocket never came up — or a real error is hiding behind it. The one-flag fix, the host allowlist, and the tests.
Twilio error 53000 ("Signaling connection error") means the client could not establish or could not keep the secure WebSocket it uses to talk to Twilio's signaling servers, and the SDK had no more specific code to describe what went wrong. You're seeing it for one of two unrelated reasons: either the network path to wss://voice-js.roaming.twilio.com/signal is blocked, or a specific server-side error is being reported to you as 53000 because a Voice SDK flag is off by default. Check the flag first — it takes one line and eliminates sixteen possible causes — then prove the network path with the commands below.
53000 is SignalingErrors.ConnectionError in the SDK, and its explanation string in the source is exact about its scope: "Raised whenever a signaling connection error occurs that is not covered by a more specific error code." Signaling is the control channel — registration, call setup, hangup, DTMF. It is separate from the media channel that carries audio, so 53000 says nothing about microphones, codecs, or ICE.
The confusing part is that one code number covers two SDKs that behave differently. Twilio's error page for 53000 is written for the Video SDK, which is why its advice talks about rejoining "the Room": there, 53000 is terminal, raised after the SDK has already exhausted its automatic reconnection attempts.
In the Voice JavaScript SDK it isn't a single fatal event. The transport raises it every time the signaling WebSocket closes with code 1006 (abnormal close — the server was unreachable) or 1015 (TLS handshake failure), and then reconnects on a backoff whose maximum delay is 20 seconds and whose default duration for the primary edge is unbounded. The Voice symptom, then, is a slow drumbeat of identical 53000s in the console rather than one clean failure, and a device that never reaches the registered state. The Voice SDK error-code list gives it a narrower gloss too — "the WebSocket timed out during pre-flight" — which matches those transport timeouts: 5 seconds to open a socket, 15 seconds without a heartbeat before the connection is presumed dead.
If your calls connect fine and then drop mid-conversation, this is the wrong page: that path emits 31005, the gateway hangup. If the SDK hands you a bare "general error" 31000, that's the Voice SDK's other catch-all, with its own diagnosis path. If signaling connects and calls start but the audio never flows, the failure is on the media plane — see WebRTC ICE connection failed.
This is the step almost every write-up on 53000 misses, and it's the highest-yield thing on this page.
The Voice JavaScript SDK ships a flag called enableImprovedSignalingErrorPrecision, and it defaults to false. While it is off, sixteen distinct server-side errors are collapsed into a bare 53000 before they reach your error handler. Turning it on costs one line:
import { Device } from '@twilio/voice-sdk';
const device = new Device(token, {
enableImprovedSignalingErrorPrecision: true,
logLevel: 'debug',
});
device.on('error', (twilioError) => {
console.log(twilioError.code, twilioError.description);
console.log(twilioError.causes, twilioError.solutions);
});
Here is what stops hiding when you do. Every code in the left column arrives as 53000 with the flag off:
| Real error | Code with the flag on | What it actually is |
|---|---|---|
ApplicationNotFoundError | 31001 | The TwiML App SID in your token doesn't exist |
ConnectionDeclinedError | 31002 | Twilio declined the connection |
ConnectionTimeoutError | 31003 | Signaling request timed out server-side |
MissingParameterArrayError / MaxParameterLengthExceededError | 31101 / 31103 | Bad params passed to device.connect() |
AuthorizationTokenMissingError | 31102 | No token reached the signaling layer |
InvalidBridgeTokenError | 31104 | Bridge token rejected |
InvalidClientNameError | 31105 | The identity in your token has illegal characters |
ReconnectParameterInvalidError | 31107 | Reconnect payload rejected |
AccessTokenSignatureValidationFailed | 31202 | Token signed with the wrong secret |
NoValidAccountError | 31203 | Account SID unusable — wrong credentials or account state |
JWTTokenExpirationTooLongError | 31207 | Token TTL exceeds Twilio's maximum |
NotFound / TemporarilyUnavailable / BusyHere | 31404 / 31480 / 31486 | The client you dialled isn't reachable |
Decline | 31603 | SIP-level decline |
Read that table against the folk remedies you'll find on Stack Overflow for this error and they stop looking like superstition. "It was a blank space in the identity string" is InvalidClientNameError (31105) — Twilio's docs restrict identity to alphanumeric characters and underscores, up to 121 characters. "I was using Test Credentials instead of Live Credentials" and "a client forgot to settle a bill" are both NoValidAccountError (31203). None of those are network problems, and no amount of firewall work will fix them; they only looked like a signaling failure because the flag was off.
Three codes are always reported precisely regardless of the flag — 31201, 31204 and 31205 — so an expired or invalid access token surfaces under its own code rather than as 53000. That asymmetry is useful: if flipping the flag turns your 53000 into a 31xxx, stop reading here and go fix that code. If it stays 53000, the failure is genuinely at the transport layer, and the rest of this page applies.
The flag has been available since @twilio/voice-sdk 2.8.0 (October 2023) and is still opt-in as of 2.18.3 (May 2026). Check what you're actually running with npm ls @twilio/voice-sdk before assuming you have it.
If 53000 survives the flag, the WebSocket is being blocked. Send your network team this list rather than "please allow Twilio" — the signaling plane is a small, specific set of destinations, all outbound TCP 443.
| Purpose | Destination | Protocol / port |
|---|---|---|
Signaling, default (edge: 'roaming') | voice-js.roaming.twilio.com | WSS over TCP 443 |
| Signaling, pinned edge | voice-js.{edge}.twilio.com | WSS over TCP 443 |
| Voice Insights events | eventgw.twilio.com, eventgw.{region}.twilio.com | TCP 443 |
| Media (audio) | UDP to 168.86.128.0/18 | UDP 10000–60000 |
| Legacy signaling, SDK < 2.3.0 | chunderw-gll.twilio.com, chunderw-vpc-gll.twilio.com, chunderw-vpc-gll-{region}.twilio.com | WSS over TCP 443 |
Valid {edge} values are sydney, sao-paulo, dublin, frankfurt, tokyo, singapore, ashburn, umatilla and roaming, plus the -ix interconnect variants. The full WebSocket URL the SDK opens is wss://voice-js.{edge}.twilio.com/signal — the /signal path matters if anyone is writing proxy rules by URL.
Two traps live in this table. The chunderw hostnames are the ones most corporate allowlists still contain, because they're what every older tutorial lists; they are only used by SDK versions below 2.3.0, so an allowlist built in 2021 will not admit a 2026 SDK. And the media row is not a 53000 fix — if signaling connects but audio doesn't, that UDP range is your problem, not this page.
For reference, Twilio's stated per-call bandwidth is 40 kbps up and down with Opus, 100 kbps with PCMU, with target conditions of under 200 ms round-trip latency, under 30 ms jitter and under 3% packet loss.
Run these from the machine that fails, on the network that fails. The output below comes from a real run on a healthy connection, 13 August 2026.
1. Does DNS resolve, and to what?
nslookup voice-js.roaming.twilio.com
You should see a CNAME to roaming.voice-js-gll.twilio.com and several A records. NXDOMAIN or an internal 10.x address means split-horizon DNS or a filtering resolver is intercepting the lookup. Twilio's Global Low Latency routing also requires that your resolver support RFC 7871 client-subnet and sit in the same region as the client; a VPN that tunnels DNS to another continent gives you a distant edge and the latency that comes with it.
2. Is TLS on 443 reachable, and is anything intercepting it?
openssl s_client -connect voice-js.roaming.twilio.com:443 \
-servername voice-js.roaming.twilio.com </dev/null 2>/dev/null \
| openssl x509 -noout -issuer -subject
Our run returned:
issuer=C=US, O=Amazon, CN=Amazon RSA 2048 M04
subject=CN=voice-js.singapore.twilio.com
Two things to read here. The issuer should be a public CA; if it names your company's own root, a TLS-inspecting proxy is terminating the connection, which is the classic source of WebSocket close code 1015. And the subject CN tells you which edge GLL actually routed you to — we were in India and landed on Singapore. If that CN is somewhere implausible for your users, DNS is the reason, and pinning edge in the Device options is the workaround.
3. Does the WebSocket upgrade complete?
curl -sS -i -N --http1.1 --max-time 5 \
-H "Connection: Upgrade" -H "Upgrade: websocket" \
-H "Sec-WebSocket-Version: 13" \
-H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
https://voice-js.roaming.twilio.com/signal
A working path answers with HTTP/1.1 101 Switching Protocols and then hangs until --max-time kills it — that hang is correct, since the server is waiting for the SDK to authenticate. A proxy that blocks WebSockets answers with a 403, a 400, an HTML block page, or nothing at all.
Keep --http1.1 in that command. Without it curl negotiates HTTP/2, the upgrade headers are meaningless, and you get back HTTP/2 403 from a perfectly healthy network — we hit that on the first attempt and it looks exactly like a firewall block.
When it fails for a handful of people on the same build that works everywhere else, the differences are environmental, and they're worth checking in this order.
Corporate proxy or TLS inspection. Many enterprise proxies permit HTTPS and quietly drop the WebSocket upgrade, which produces a 1006 close and a 53000 within seconds of device.register(). Command 3 above settles it in one shot.
VPN. Split-tunnel VPNs change both the DNS answer and the egress IP. Ask the user to disconnect and retry; if the error clears, the VPN's DNS or its egress firewall is the blocker, not your code.
Browser extensions. Ad blockers, privacy extensions and corporate security extensions can intercept WebSocket connections. Reproduce in an incognito window with extensions disabled before escalating anything.
A stale allowlist. See the chunderw note above — this is the single most common corporate-network cause of a 53000 that appears only after an SDK upgrade.
If a whole region fails rather than individuals, pin the edge and give it a fallback. The SDK accepts an array in priority order and moves to the next entry when a connection attempt closes with 1006 or 1015:
const device = new Device(token, {
edge: ['dublin', 'ashburn'],
enableImprovedSignalingErrorPrecision: true,
});
For a device that also has to survive network changes during a call, maxCallSignalingTimeoutMs (default 0) sets how long the SDK keeps trying to get back to the most-recently-used edge before it gives up on that call. A device stuck unregistered after a signaling failure is a related but distinct symptom — Twilio Device offline covers that state machine.
Open DevTools before you call device.register(), then go to Network and filter by WS. You are looking for a request to signal on a voice-js.*.twilio.com host.
register() or connect() was actually called, since no socket is opened at construction time.Set logLevel: 'debug' on the Device and the console prints the transport's own view, including the line Received websocket close event code: <code>. Reason: <reason> — the reason string frequently names the proxy that rejected you.
The SDK ships a diagnostic that does all of the above with a real test call, which is the fastest way to get evidence from a user you can't sit next to:
import { Device } from '@twilio/voice-sdk';
const test = Device.runPreflight(token);
test.on('connected', () => console.log('signaling up'));
test.on('failed', (error) => console.error('preflight failed', error));
test.on('completed', (report) => {
console.log(report.networkTiming.signaling); // start/end/duration in ms
console.log(report.callQuality); // excellent … degraded
});
The report separates signaling timings from DTLS and ICE timings, so it distinguishes a 53000-class failure from a media-plane one without guesswork. It needs a token whose TwiML App points at an endpoint that can record and play back audio, and the test places a real (billable) call.
enableImprovedSignalingErrorPrecision: true and re-run. If a 31xxx appears, debug that code instead.npm ls @twilio/voice-sdk — anything below 2.3.0 uses the old chunderw hostnames.voice-js.roaming.twilio.com and TCP 443 explicitly.edge with a fallback array, then run the preflight test to confirm.What's the difference between Twilio error 53000 and 31005?
53000 is a signaling connection error with no more specific classification, usually raised while connecting or registering. 31005 is a connection error on an established call — the gateway hung up. If both appear, debug 53000 first: with no signaling channel, nothing else can work. Note that the two share the class name ConnectionError in different SDK namespaces.
Does 53000 mean my access token is invalid? Not usually. Token expiry and invalidity report as 31205 and 31204, which the SDK surfaces precisely whether or not the precision flag is set. Two auth failures do hide behind 53000: a signature mismatch (31202) and an unusable account (31203), which covers test credentials and unpaid balances.
Does an unpaid Twilio balance cause error 53000?
Yes, indirectly. An account that Twilio won't accept calls for raises NoValidAccountError (31203), which is reported as 53000 while enableImprovedSignalingErrorPrecision is off. Check the balance and account status in the Console before spending a day on firewall rules.
Is opening TCP 443 enough to fix 53000?
For signaling, yes — the WebSocket runs over WSS on 443 to voice-js.{edge}.twilio.com. Audio does not: it needs outbound UDP to 168.86.128.0/18 on ports 10000–60000. Open only 443 and you'll clear 53000 and land on a silent call instead.
Is Twilio error 53000 a Video-only error? No. The code is shared: Twilio's documentation page for it is written for the Video SDK, but the Voice JavaScript SDK raises the same 53000 from its WebSocket transport. Voice's own error-code list describes it as the WebSocket timing out during pre-flight.
Could 53000 be a Twilio outage? Rarely, and it costs ten seconds to rule out at status.twilio.com. A real outage hits every user at once; 53000 concentrated in one office, one VPN, or one browser profile is a local network problem.
The single highest-yield fix on this page is a boolean that ships false. That's the shape of most signaling work: not hard, just undocumented, and discovered during an incident rather than a design review. Alloqui builds the Device for you — enableImprovedSignalingErrorPrecision on, log level set, the sixteen collapsed error codes surfaced with their real numbers before they reach you. You paste your Twilio keys and drop a <Dialer /> into your React app. We can't open your customer's firewall, but you'll know within one call whether that's actually the problem.