What's actually wrong with Titanfall 2's lobby servers
TL;DR: individual official lobby instances tear down their own lobby every few seconds while you're sitting in it. It is not your connection, not a kick, and not the whole region — the broken unit is one port on one machine, and another lobby on that same machine can be perfectly fine at the same moment. It also stops on its own. The tool below tells you which one you're on.
https://github.com/mrcook1e-ai/tf2mon — Windows, no install, MIT.
It's a passive tracer that sits inside the game, decrypts the netchannel and writes down what the server actually sends. Everything below is measured across 42 recorded sessions.
What is actually happening
When the lobby reloads over and over, this is the sequence on the wire:
- You connect to an official lobby, and it comes up normally.
- You reach
FULL— loaded, in the lobby, playing. - The server sends
CHANGELEVELinto that live session. - The lobby reloads, and the instance's own generation counter ticks up by one.
- Repeat.
You are never disconnected, never rejected, never kicked. The connection stays up the whole time and the engine's disconnect path never fires once — which is exactly why you get no error message explaining anything. The client is doing what it's told.
In 82% of the teardowns I recorded, the client had reached FULL first. So
this isn't a session failing to come up. It's a finished, working session being
torn down.
1. There are only two places
The menu offers about a dozen datacenters. Those addresses are ping targets — the game pings them to draw the bars. They are not where you play.
Every lobby server I have actually been connected to was in one of two places:
- EU — Frankfurt, Germany
- US — Columbus, Ohio
Both Amazon (AS16509). Picking London or Amsterdam gets you Frankfurt. When I deliberately picked Asian datacenters, or Sydney, I landed on Ohio. Across 42 captures a third location never appeared once.
The menu decides which of two pools you land in. That is all it decides.
2. The broken thing is a port, not a machine
This is the finding that changed how I read everything else.
One capture caught four lobbies on the same host IP, differing only by port. One held a clean session throughout. The other three were reloading every few seconds — at the same time, on that same machine.
So it isn't an overloaded box and it isn't a regional outage, and your friend's lobby being fine tells you nothing about yours. The instance is the (IP, port) pair. When you bail out of a broken lobby and land somewhere better, what changed was usually the port.
3. The matchmaker assigns your instance, and can move you
You don't pick an instance, you're given one. It can also shuffle you: in one capture the client was passed between two instances seven times, and neither had restarted — both generation counters sat still the whole time. That's a second, separate failure, and from inside the game it looks exactly like the first one.
Queue into US and then back into EU and you can come back to a different instance than the one you left. Sometimes that's the fix. Sometimes it hands you something worse.
4. The counter: history vs. diagnosis
Each instance broadcasts how many times it has reloaded since its process
started. The tool shows it as no.
Above 1 means it has already been restarting. Lining up the nine instances where I could check this cleanly: joined at 1–2, held 3 times out of 3; joined at 3 or higher, held 1 time out of 6. Small sample, but it points where you'd expect. A history is no guarantee it'll happen to you, but it's the cheapest warning sign you can read at a glance, and I'll take a fresh instance over a veteran every time.
The exceptions are real and not marginal, though. The healthiest instance I ever recorded sat at 72 and held four separate visits without one restart; another at 221 was fine with 31 players. The counter says how many, never when — something that piled up 72 over several hours may have been calm for the last twenty minutes.
What tells you it's sick right now is whether that number is moving.
The tool shows that separately, as gens. no is what it did before you
arrived; gens is what it's doing to you.
5. It's a state, not a rate — and it ends
It's a metronome. 24 consecutive cycles measured between 2.22 and 2.78 seconds; full cycle about 5.15 s. Server→client packet loss across tens of thousands of packets: 0.00%. Nothing is being lost on the way, and that precision is not what overload or a crash looks like.
There's almost no middle ground. Of 255 generations the server tore down itself, the median lived 2.85 s, the longest 43.5 s, and not one survived past a minute. An instance either tears the lobby down within seconds or doesn't tear it down at all.
And it stops by itself. I watched two instances settle inside a single visit — no reconnect, nothing I did. One tore down five generations in a row at six-second intervals, then held the next for 285 seconds straight. In another capture an instance had been looping for at least fifteen minutes — 67 restarts, one every 13 seconds — before it quit and then held clean across four visits.
So it's an episode, with a beginning and an end. Reconnecting frantically isn't always the answer; sometimes you're thirty seconds away from it fixing itself. Don't call it early either: one instance held 43 seconds and dropped straight back in.
What is still unknown
I can see what the server does. I can't see why it starts. That needs EA's server-side logs, and no amount of client-side recording will substitute.
What the data does rule out is anything that would have to be shared by a whole machine or region: three lobbies looping while a fourth on the same host stays clean is not an overloaded server, and 0.00% loss is not a network problem. Player count isn't a trigger either — I recorded a lobby with 31 players and zero restarts, and one with 8–11 players restarting five times.
I can't honestly say whether this is a bug, a corrupted instance, or something deliberate. Whatever starts it also ends it, unattended, and any explanation has to account for that too.
What I want to try next
The server sends CHANGELEVEL and the client obeys. I want to see what happens
if the client doesn't — if I drop that one message, does the lobby just
stop reloading?
It may well not work. The server tracks how far the client has acknowledged sign-on, so a client that quietly refuses to follow the level change may get ignored, time out, or end up in a state the server won't talk to. It's very much not vanilla behaviour. But it's the one experiment that turns "watching the problem" into "not having the problem", so I'll run it and report back either way.
Using the tool
Download it, run it, press c, play. Close the game and it tells you what each
server you touched was doing:
| verdict | meaning |
|---|---|
HEALTHY |
holds the session |
SICK |
reloading its own lobby in a loop |
STALLING |
the world freezes for seconds and resumes — playable, degraded |
BOUNCING |
you're being passed between instances |
RECOVERED |
it was looping and stopped |
It remembers addresses between sessions, so coming back to a server an hour later shows what it did last time. That's the difference between reconnecting blind and reconnecting on purpose.
Nothing to buy, nothing to sign up for. "Is it me or is it them" should be a question with an answer, and now you can post a screenshot instead of an argument. If you run it, I'd genuinely like to see what instances look like from other regions — mine is one vantage point, and two of the findings above are limited by that.
The full write-up is in the repo, including the r2 message layout, which I had to measure myself because no public table for it exists. The findings documents are in Russian; the code and README are in English.
Read this before you run it
It injects a DLL into an online game. I won't dress that up: it goes against EA's terms of service, and it may upset your antivirus. Your call, not mine.
What it does not do: it doesn't modify a single message or any game logic, it always calls the original handlers, and it contains no anticheat bypass and no attempt to hide itself. It reads, and it writes down. That's the whole program. It refuses to record if the game was launched with dev switches, or if the engine build doesn't match the one the hooks were verified against — a half-instrumented capture is worse than none.
Don't upload your .vnt captures anywhere. They hold your session's
decrypted traffic: the lobby roster with player identifiers, your own
persistence data, everything the server sent you. Keep them local. If you want
one explained, run the tool's own report or analyze and paste that text
into an LLM — it reads it well. Paste the report, never the capture.
I wrote an earlier comment about this before I had the measurements; it's outdated and this post replaces it.