Let the NAT fix use a relay the blocked player can actually reach

[greluc]

Turning the NAT fix on can move a player to a relay they cannot reach.

What it did

const config = SettingsStore.store.natFix ? DEFAULT_ICE_CONFIG_TURN : this.iceConfig;

The switch means "route everything through a relay", not "route everything through this relay". Substituting the constant throws away what the server sent, so a self-hosted deployment with its own relay had its players' audio sent through turn.bettercrewl.ink instead — and any transport, port or credential that operator configured went with it.

The policy is now forced onto the list we were given, and the built-in relay is used only when the server offered none to force through.

That alone does not connect

A turn: URL with no ?transport= means UDP. The networks that need a relay are largely the ones blocking UDP — schools, offices, some mobile carriers — so a player there gets working signalling (it is WebSocket over TLS), avatars that light up when people talk, a lobby that looks completely healthy, and no audio in either direction, because no allocation is ever made.

So every bare turn: URL now also gets a TCP form:

• deduplicated against what the server already advertised — a server that lists both must not cause two allocations for one relay, and a relay's port range is finite;
• plain URL first, since ICE tries candidates in the order given and TCP is the worse path for anyone who can use the other;
• turns: untouched — it is TLS over TCP already — as is any URL whose author named its transport.

The built-in fallback gets the same treatment, and that is the case that made this worth doing. DEFAULT_ICE_CONFIG_TURN is a single UDP-only URL, so before this a player who turned the NAT fix on, on a server advertising no relay, was moved by the rescue switch to a relay they could not reach.

One transport per peer

Connections now ask for bundlePolicy: 'max-bundle'. Voice and the data channel share one transport: one set of connectivity checks, one DTLS handshake, and one relay allocation per peer instead of two at peak.

Honest about the size of this one: BUNDLE is negotiated by both ends anyway, so the extra transport is merged and its allocation released once the answer arrives — the cost is peak, not steady-state. It matters because a ten-player lobby is forty-five connections allocating at once during a fill, and a relay's reservations are finite. Both ends of every connection are this same client, so there is no peer that might not support it.

Verification

The decision and the helper are extracted from ConnectionController.ts and driven over six configurations, so the same script runs against either revision:

	nightly	this branch
NAT fix off, server offers a bare relay	all [stun, turn:relay]	ok — TCP form added
NAT fix on, server offers a bare relay	relay [turn:turn.bettercrewl.ink]	ok — the server's own relay
server advertises both transports	substituted away	ok — exactly one TCP entry
a turns: relay	substituted away	ok — left as advertised
NAT fix on, no relay advertised	relay [bettercrewl.ink], UDP only	ok — TCP form added too
UDP offered before TCP	—	ok
every path asks for max-bundle	no	ok

Seven assertions, all failing before and passing after. The nightly column is worth reading on its own: every case collapses to the same hardcoded URL, whatever the server advertised.

lint, typecheck, format:check, verify:esm and build pass, and prettier reports the file unchanged. CI was run on a fork before this was pushed.

Limits, stated plainly

Nothing here was run against a real UDP-blocking network or a real relay. What is verified is which ICE configuration the client builds, not that a TURN server answers on TCP at the port it advertises — a relay that does not simply produces no candidate from the extra entry, which is why adding it is cheap.

The TCP form is added on every path, not only when the NAT fix is on. That is deliberate — a player behind a UDP-blocking firewall is in the same trouble whether or not they found the switch — but it does mean this changes the candidate list for everyone, not just for people who turned something on.

I have not measured the peak-allocation claim against a live relay's counters; it follows from one transport rather than two, not from an experiment.

Disclaimer

This change was written with AI assistance (Claude Code). The author reviewed it, and the table above is real output from a script driving the real code on both revisions, not a description of intent. Please review it as you would any patch from a stranger; if something here is wrong I would rather hear it than have it merged.

🤖 Generated with Claude Code

[github-actions]

Download the artifacts for this pull request:

• BetterCrewLink Unpacked 64bit.zip
• BetterCrewLink Installer Windows.zip
• BetterCrewLink Installer Linux.zip

---

This service is provided by nightly.link. These artifacts will expire in 90 days and will not be available for download after that time.