The X questions that reach r/automation and BlackHatWorld are rarely "which proxy". They are symptoms. "I'm getting an error ('Oops! Something went wrong. Try again later') before I can even get a verification code sent to my email." And the one sitting under all of them, from a BlackHatWorld thread: "will adding residential proxies now hurt the accounts in any way?"
This post is for the person holding one of those symptoms and wondering whether the IP caused it. Sometimes it did. Usually it did not. The honest version: X does not ban IP addresses as a rule. It scores accounts, and the IP feeds that score at two moments, the signup (what the exit address has done before) and every session after (whether the country and network stay the same). Everything else people bring is account-level trust or a rate limit, and each section below says which.
"Oops! Something went wrong" before the verification code arrives
That error at signup means X refused the request before an account existed, so the thing being judged is the IP's reputation, the email, or the browser, in that order. An r/automation poster laid out a setup that looks right on paper: "I've had no trouble running a lot of marketing accounts right on my actual IP up until recently", then an antidetect browser on default settings, "residential proxies ... that are stickied and have a location of the city I live in, and bought Gmail 2 year old accounts." Their conclusion: "I must be leaking somewhere though, and I'm not sure how."
Start with the IP, because it is the cheapest to test. A sticky residential IP in your own city is fine in principle. But a residential exit is shared, and the previous person on that address may have made accounts from it too. Run the address through the fraud score tool. Then put the proxy into a plain Chrome with nothing installed and sign up with a fresh mailbox on a domain you control. If that works, the leak is the browser profile. If it fails, ask for a different IP and repeat.
The email is the second suspect. A mailbox you did not create has a history you cannot see, and X reads the domain and the age of the address. We do not advise bought Gmail accounts. They are one more variable you cannot control.
The browser is last. Defaults in an antidetect browser are not the problem by themselves. A mismatch is: a profile that claims a Windows machine in one timezone, exiting from an IP in another. Our antidetect browser and proxy post covers what to line up.
"Account does not have authentic..." and the account that cannot tweet
The authentic flag and the silent posting block are account trust states, and no proxy clears them. A BlackHatWorld thread titled "How to fix Twitter Authentic flag?" opens: "I warmed up couple aged accounts, using good proxy, all manual work but it still shows this message." Another thread, "twitter won't let me tweet, but i can do anything else", describes replies going out and then the notifications from them vanishing.
Both mean X does not trust the account, and X decides that from what the account has done, where it came from, and how it behaves. An aged account bought from someone else carries whatever it did before you owned it. A good proxy does not rewrite that.
What the IP contributes from here on is consistency. The one thing you can do on the network side is stop hopping between addresses and countries. Give it one fixed IP in the country it claims and leave it there. Whether the flag lifts is then up to the account's behaviour, and up to X. We do not have a trick for it. Nobody does.
The country label on your profile
X derives the location shown on a profile from signals that include the IP addresses the account connects from and the app store region of the phone it is used on, so a consistent proxy in one country keeps the label consistent and a VPN that hops countries makes it wrong. A BlackHatWorld thread titled "Circumventing the X location update" has the snippet: "X uses IP and account signals but using a stable VPN or proxy can shift the detected country a lot though it's never guaranteed."
The exact rule is not published. What you can control is that every session comes from the same country on the same kind of network. A UK account on a fixed UK IP shows the UK. The same account on a VPN that lands in Frankfurt on Monday and Ashburn on Tuesday shows whatever X decides, and the inconsistency itself is a signal.
We do not advise faking a location to deceive an audience. An agency running a client's German account from Lisbon has a legitimate reason to use a German IP: the account is German.
429 errors and account locks when scraping X
A 429 from X while logged in is a per-account rate limit, so rotating the IP behind that account changes nothing and burns your gigabytes. From r/automation: a Selenium scraper "worked fine for a few days, but then I started running into constant 429 errors, account locks, and unreliable results, even with delays. I also tried rotating residential proxies, which got expensive fast, but it still didn't solve the problem consistently."
Of course it did not. The limit is attached to the session cookie, which travelled with every request no matter which IP sent it. Once the counter is full, X does not care where the next request comes from. So the poster paid per GB to change the one variable X was not looking at. Logged-out access is limited too, and shows very little.
The honest answers are fewer requests, slower ones, more accounts each on its own IP and profile, or X's paid API. The poster's volume was "maybe a few thousand tweets per week", which is small enough that the API is the sane choice. Browser-based scraping follows the same rule as any account: one fixed address per account, kept. Our post on when a scraper gets blocked separates IP blocks from account blocks.
Adding a proxy to accounts that already exist, and coming off a VPN
A one-time move from your home IP to a fixed IP in the same country is a normal event, because people move, so do it once and keep it. The BlackHatWorld poster asking for cheap residential proxies had the right worry: "I already have active accounts set up and have posted on them will adding residential proxies now hurt the accounts in any way?"
Same country, fixed address, done once: no. Moving to a rotating pool: yes, since an address that changes every few minutes looks like nothing a person does. A different country: also a change X notices. The word "residential" in the question matters less than the word "rotating". A fixed ISP IP and a sticky residential session both look like a home connection; one of them stays.
The r/VPN poster who was "Shadowbanned from X" is the same problem from the other side. They use a VPN "with anonymous reputation", get "frequently flagged as suspicious", and asked: "datacenter ones might be blacklisted too and residential proxies are very expensive .. any solutions in between?" VPN ranges sit on lists because every neighbour in the block is a VPN exit. A dedicated ISP IP on a consumer range is the in-between: one address, yours, on a network that says home internet. More in our post on one static residential IP for yourself.
The setup
One fixed IP per account, in the country the account claims, on a consumer-ISP range, is the whole IP-side answer for X. ISP proxies are the fit, dedicated and fixed for the rental, in the US, GB, DE, FR, JP and HK; the product side is on our Twitter proxies page.
The r/marketing question "Mobile or residential?" gets the same answer. Mobile IPs are shared and change, which suits one account that should look like a phone, not a dozen accounts that should look like a dozen people. We wrote a longer piece on when you actually need mobile proxies. For X, most people do not.
At fleet size the rule does not change, the count does. The r/automation poster running "50+ X/Twitter accounts 24/7" on Puppeteer listed what broke: session management "needs isolated user-data-dirs per account", and "human-like pacing", because "bursts of identical actions" got noticed. The proxies are not on that list, because each account had its own. One IP, one profile, one pace per account. Larger farms are the same rule multiplied.
Scheduling tools are not an IP matter. The BlackHatWorld poster asking "Can using Buffer get me banned on X?" is using the official API through an approved app, and X sees Buffer's servers, not your proxy.
FAQ
Does X (Twitter) ban IP addresses?
Not as a rule. X scores accounts, and the IP is one input: its reputation at signup, and whether it stays consistent afterwards. A burned exit can get a signup refused, but locks land on the account, and a fresh IP alone does not lift them.
Why do I get "Oops something went wrong" when creating an X account?
Because X refused the signup before an account existed, which points at the IP's reputation, the email address, or the browser profile. Test the IP by itself in a plain browser with a fresh mailbox on a domain you own; if that passes, the leak is the browser profile.
Will adding a proxy to my existing Twitter accounts get them banned?
A single move from your home IP to a fixed IP in the same country is normal, because people move. Moving to a rotating pool or to another country is a change X can see. Do it once and keep the address.
Mobile or residential proxies for Twitter accounts?
For accounts you keep, a fixed IP on a consumer-ISP range, one per account, in the account's country. Mobile IPs are shared and rotate, which is what a single phone looks like and not what twelve separate people look like.
How does X decide the account location shown on my profile?
From signals including the IP addresses the account connects from and the app store region of the device. A consistent IP in one country keeps the label consistent; a VPN that changes countries makes it wrong or flags it. The exact rule is not published, and we do not advise faking a location to mislead anyone.
Why do I get 429 errors scraping Twitter with residential proxies?
Because the 429 is a per-account rate limit tied to the session, not to the IP, so rotating addresses behind one login changes nothing and costs gigabytes. The real options are fewer requests, slower pacing, more accounts each on its own fixed IP, or X's paid API.
Can a proxy fix the "Account does not have authentic" flag?
No. The flag is X's trust rating of the account, built from its history and behaviour, and the IP does not rewrite history. What the IP can do from now on is stop adding inconsistency: one fixed address, one country, kept.