Why LinkedIn signs you out, and why it is almost never your IP

A LinkedIn session is not a password. It is a long string in a cookie that says "this browser already proved who it was". Which means it can be copied, and which means LinkedIn has to decide, on every request, whether the thing holding that string is still the thing it was handed to.

Most advice about staying signed in is about IP addresses. Use a residential proxy. Match the country. Do not use a datacenter range. We followed all of it and still watched two live sessions die inside a minute, so we went and checked what actually separates the accounts that survive from the ones that do not. The answer was not the address.

Here is what we measured, what we got wrong first, and what it means if you use any tool that touches your LinkedIn account.

What happened

We were testing a flow that takes a LinkedIn session cookie and makes one request with it, to confirm the session works before anything else uses it. One request, to LinkedIn's own endpoint for "who am I".

The first attempt came back with a 302 and a revoked session. Not an error, not a rate limit. LinkedIn had decided the session was no longer valid, and it had decided that everywhere: the person whose cookie it was got signed out of their own browser, on their own laptop, mid-session.

We found a real bug, fixed it, and tried again with a fresh cookie. The second attempt succeeded at 10:24

. About sixty seconds later, the same cookie from the same address came back 302 revoked, and the owner was signed out of their own browser again.

So the first fix was necessary and it was not the answer.

What we got wrong

Our first theory was rotation, and it was a real defect worth writing down.

The validation step was using an anonymous scraping pool, which rotates its exit address on purpose. Anonymous scraping has no account to stay consistent for, so rotating is correct there. But this request carried a live authenticated cookie, and rotation meant one session appeared from two unrelated residential addresses about a second apart.

That is a good description of a stolen cookie being replayed, and it is a reasonable thing for LinkedIn to kill. We fixed it. The session still died.

Our second theory was the broad one, the one most articles land on: using a session through a proxy at all is what kills it.

That one is simply false, and we can show it.

The number that rules out the obvious answer

We looked at every active LinkedIn account on our platform. 1,687 of them, all running through the same proxy path, every day.

23 were signed out. That is 1%.

If routing an authenticated session through residential infrastructure killed sessions, that figure would not be 1%. Ninety nine percent of these accounts do this all day and stay signed in for months.

So the question stopped being "does proxying kill sessions" and became "what do those 23 have that the other 1,664 do not".

It was the device, not the address

Only one request in the flow actually carries the session. The other one sends an empty cookie value, which is worth knowing because it is the difference between diagnosing this by reading and diagnosing it by burning somebody's account.

Here is what that one request looked like, against what the owner's own browser looks like:

None of those is an IP problem. Together they are a different machine.

And a session appearing on a machine LinkedIn has never seen is a textbook stolen-cookie signature, which explains the part that surprised us most: the owner was signed out too. LinkedIn was not blocking our request. It was protecting the account from what it had every reason to read as a theft.

Why the other 99% are fine

This is the part that reframes the whole problem.

The accounts that survive are not on better addresses or better proxies. They are on the same ones. What they have is history: their cookie has been presented from that same server-side fingerprint for months, so it is a known device now. Boring, familiar, unremarkable.

A freshly pasted cookie has no history at all. It has only ever existed in one browser, on one machine. The first time it shows up anywhere else is the single moment it can be disbelieved.

The transition is the risk, not the proxy. And it happens exactly once per account, and it cannot be retried, because the thing you would retry is the thing that revoked the session.

The same lesson, in a second dimension

Sessions are not the only thing LinkedIn judges by shape rather than by amount. We have one other measurement that says the same thing, and it is worth putting next to this one because it is the mistake people make while carefully respecting every published limit.

An account of ours was flagged as a bot. The obvious suspect was connection requests, because we had started sending them that week. The account's own records said otherwise.

A column chart of profile visits per hour across one day. Twenty three of the hours hold nine visits between them and sit flat against the baseline. The hour at 17 holds 497 and towers over them. The day total is 506, which no daily limit would flag.

506 profile visits in a day is not a remarkable number. 497 of them inside one hour is a machine, and no amount of staying under a daily ceiling hides it. The connection requests that day were the control group: 13 of them, five minutes apart, not one refused.

So the daily limit everybody optimises around was never the thing being watched. The rate was.

There is a second-order version of this that is easy to get wrong in the other direction. A perfectly even pace, one action exactly every three minutes, is also a machine. Regularity is itself a fingerprint, so the spacing has to vary the way a person's would.

What this means if you use LinkedIn tooling

You do not need to know how any of this is implemented to act on it. Four things follow directly.

Connecting your account is the risky moment, not using it. If a tool is going to lose your session, the overwhelmingly likely time is the first minutes after you connect it, not week three. That is also when you are least invested, so it is the right moment to be paying attention.

Country matching is not device matching. Our account was French and we egressed from France. It was not close to enough. Any tool telling you that geography is the safety story is describing one field out of six.

One account, one place. Every additional tool holding the same session is another device claiming to be you. Two is riskier than one for reasons that have nothing to do with how careful either one is.

A revoked session means revoked. If something answers a session check with a redirect to a login page, the answer is to reconnect, not to try again from somewhere else. Retrying from more addresses is how one dead cookie turns into a flagged account. This one is worth asking a vendor about directly, because the retry is invisible to you and it is a genuinely bad default.

What we still do not know

Worth stating plainly, because the honest version of this article ends here rather than with a tidy conclusion.

We know some accounts are revoked within a minute of an authenticated call from a new fingerprint, and that it is roughly 1% of ours. We do not know why those accounts and not the other 99%. The candidates we cannot separate yet: the owner being actively signed in elsewhere at the same moment, an account-level risk score we cannot see, or a real location that does not match what the account has on file.

We also do not know how long LinkedIn's invitation ceiling lasts, and neither does anyone publishing a number for it. Every figure you have read about weekly invitation limits is somebody's guess repeated until it sounded like documentation. We are measuring ours, per account, by recording what we predicted next to what actually happened. When that data says something, we will publish that too.

The short version

LinkedIn is not watching where you are. It is watching whether you look like the same machine that logged in.

That is good news, mostly. It means the steady state is safe, that most accounts running through infrastructure are fine, and that the whole risk is concentrated in one moment you can see coming. It is bad news for the advice industry built on picking the right proxy type, which is answering a question LinkedIn was not really asking.

Every number in this article came from our own systems this week. The two revoked sessions were ours, on a real account, and they are the reason the rest of it is written down.