LoginToolsPricing
BirdProxies
BirdProxies
Iniciar sesión
Back to Blog
Guides

LinkedIn restricted your account: what the IP changed, and what it did not

BirdProxiesSeptember 7, 20268 min read

Someone on r/automation put the confusion in one post: "I dont use proxies but i try best to act as a real user with everything randomly, like cliking on a profile, sleep, scrolling and all. Whats am i doing wrong". Their suspects were a headful browser, an idle second monitor, and no proxies. Two of those are not what LinkedIn looks at. The third matters, in one specific way. This post is about that way.

A proxy does not lift a restriction that is already on your account

LinkedIn restricts accounts mainly on what they do, and changing the IP afterwards changes nothing about that record. The heaviest signals are invitation velocity, message volume, bursts of profile views, how many invites get ignored or marked as spam, and account age. The address you connect from is one signal in that list. It is a real one. It is not the one that put the captcha in front of you.

Someone on r/GrowthHacking wrote: "I'm aware LinkedIn is super aggressive now with limits and bot detection, and I'm pretty nervous about losing my account if I automate too much. I heard about multi-account setups, proxies, fingerprinting browsers… but it feels super messy". The mess is real. The order is simple. Volume first. Then session consistency. Then the IP. LinkedIn has said it caps invitations at roughly one hundred a week, without publishing an exact figure; past that, no address on earth helps.

And a restriction already on the account stays on it. You appeal, you verify, you wait. The proxy decision is about the next account, or this one after it comes back.

The IP rule that does hold: one account, one static address, for life

The IP rule LinkedIn does enforce is consistency: an account should keep showing up from the same place, and never from a place that already carries someone else's history. A rotating residential proxy breaks both halves. The exit changes per request or session, so the account hops cities inside an hour. And every exit is shared with strangers, some of whom did things on LinkedIn you would not want attached to your login.

Someone on r/DigitalMarketing watched exactly this fail after a year of it working: "residential pools that were working a year ago are now returning failure rates in the 70-80% range because the same ips are being recycled across too many provider pools. the only config that's holding up consistently is 4G/5G mobile". We cannot check that percentage. The mechanism, though, is right. A pool exit is rented by the minute, and its reputation is whatever the last tenant left.

So for a logged-in account the choice is between two addresses that do not move. A static ISP proxy is one address, registered to an ISP rather than a data centre, that nobody else uses while you hold it. Day one, day four hundred, same address. It is the cheaper option. A 4G/5G mobile proxy is shared by design: thousands of real phones sit behind one CGNAT address, so LinkedIn cannot punish it without punishing its own users. That costs more, and when it pays off is argued in /en/blog/do-you-actually-need-mobile-proxies.

On either type, do not rotate. Never let a tool "refresh" the IP of a live account, and never share one address between two accounts. If the account has lived on your home connection for three years, leave it there. The proxy is for accounts that need a home.

The captcha loop is usually a session problem

Repeated captchas on an account with a stable address and sane volume almost always point at the browser session, not the network. LinkedIn keeps a lot there: cookies, local storage, a fingerprint built from the browser's own properties. A headless run that starts from a clean profile each morning is a new device each morning. So is an antidetect profile that got rebuilt.

Antidetect tools get blamed, sometimes fairly. A thread on BlackHatWorld: "I used Dolphin Anty, GoLogin, Incogniton for a long time and honestly for my use case (Linkedin) they were a mess and account health was 50". We could not read the replies, so that is one person's experience. What we see: a good profile, kept, with a fixed address behind it, outlives a perfect profile that gets regenerated.

Someone on r/automation, months into a DIY stack: "LinkedIn updated a frontend selector last Tuesday n my headless browser flow started throwing errors. I spent three hours fixing it before my first call ... Or ur proxy IP gets flagged." Only the second is a proxy question, with the answer above. Buying a hosted tool instead? Ask whether its IP is dedicated to you or drawn from a pool.

ID verification: do it from the address the account always uses

The safe way through LinkedIn's identity check is to complete it from the same connection the account has always used. The check runs through Persona, and a BlackHatWorld thread advises: "Use a stable IP – Avoid VPNs/proxies during verification; Persona sometimes blocks them." Half of that is right.

A rotating exit or a hopping VPN is a bad place to be during verification, true. The wrong half is the instinct to switch the proxy off, verify from home, then switch back. If the account has lived on a static ISP address for a year, the home IP is the anomaly, and a change of country mid-verification is exactly what the check exists to notice. Stay put. If Persona rejects the session anyway, that is a support case with LinkedIn; the thread says "sometimes", and we will not claim it never happens.

Buying connections is not an IP question at all

Bought connections put an account at risk through the pattern of who accepts and how fast, and no address type changes that pattern. Someone on BlackHatWorld asked plainly: "if I buy linkedin connections from someone, maybe the account gets banned easily?" Yes, for a reason with nothing to do with proxies. Hundreds of acceptances in a week from accounts that share no industry, location or mutual contacts is a graph anomaly. LinkedIn reads the graph. Your IP is not in it.

Scraping job posts logged out is a different job from scraping logged in

Fetching public job listings without an account is a bandwidth problem, and fetching Sales Navigator with an account is an account-risk problem, so the tools and arithmetic differ.

Someone on r/proxies runs a go-to-market agency and wants job scraping in-house: "I saw that the jobspy is a good alternative but I understand that I need proxies for this to operate ... what do I need, what are the providers, how much it would cost, and how to calculate how many proxies I need". Jobspy hits the public, logged-out job search, so there is no account to protect. What breaks is the rate: one address that asks too often starts getting errors or empty pages. A rotating residential proxy fixes that, because each request leaves from a different address and none asks more than a few times.

How many proxies you need

For logged-out scraping you do not count proxies, you count gigabytes and concurrency. A rotating residential plan is one endpoint, the pool behind it changes the exit for you, and it is billed per GB, so "how many proxies" turns into "how much data". For logged-in scraping the count is simpler and worse: one static address per account, and every account is one you can lose.

How to work out the cost

The formula is page weight times page count, and the page weight is the number you must measure yourself. A LinkedIn job listing is typically a few hundred KB to over a megabyte when fully rendered. Open one, open the network tab, reload, read the total transferred. Then:

GB per run = (KB per page x pages per run) / 1,048,576

Put your own numbers in. If the network tab says 900 KB and you want 5,000 listings, that is 4,500,000 KB, roughly 4.3 GB, before retries. Multiply by your provider's per-GB price. Two things move that figure. A plain HTTP fetch of the HTML weighs a fraction of a rendered page, because it skips scripts, fonts and images; jobspy works that way. And retries cost bytes too: a request that came back with LinkedIn's 999 status still went over the wire.

Can it be done for free

No, not at any volume, and the reason is the rate limit rather than the proxy market. Someone on r/webscraping asked: "from what i have read so far, one needs paid proxy rotation and other things to not get banned. how much would cost for a skilled person to do? is it must that ull have to pay for smth ?" A skilled person can write the scraper for nothing. What they cannot do is make one home connection look like a thousand. A few listings a day from your own IP is fine, and free. Past that, every free option (public proxy lists, a cheap VPN, a datacenter box) is a set of addresses LinkedIn already catalogued, and the failure rate makes "free" expensive in hours. The person on r/Affiliatemarketing who scraped "over 300 million LinkedIn leads" said "the data pipelines, retry queues, and proxy rotation logic were the toughest parts". The proxies were not the hard part. The plumbing was.

What to do this week

Restricted right now? Appeal, verify from the connection the account has always used, and cut daily actions to well under your tool's defaults before you touch the IP. Setting up an account that will live on automation? One static ISP address and one browser profile on day one, then leave both alone. Scraping public job posts? Measure one page in your network tab, run the formula above, and buy that many gigabytes plus a margin. The address types for both are at /en/proxies-for/linkedin.

Get started with BirdProxies

Put this into practice with fast, reliable proxies built for social media, scraping, and automation.

Residential ProxiesReal home IPs across 195+ countries for maximum trust.ISP ProxiesDatacenter speed with residential legitimacy.

On this page

BirdProxies
BirdProxies

Fast, secure, reliable proxies. ISP, Residential, and Mobile, ready when you are.

Products

  • ISP Proxies
  • Residential Proxies
  • Sneaker Proxies
  • Ticket Proxies
  • Crypto Proxies
  • Social Media Proxies
  • Betting Proxies

Company

  • Pricing
  • Partners
  • Imprint
  • Terms

Resources

  • Blog
  • Docs
  • Glossary
  • Integration Guides
  • Compare Providers
  • FAQ
  • Changelog
  • Brand Assets

Connect

  • Dashboard
  • Sign Up
  • Contact

© 2026 BirdProxies. All rights reserved.

PrivacyCookiesRefunds