← back to blog

2026 multi-account playbook for X (Twitter): proxies and ban-avoidance

2026 multi-account playbook for X (Twitter): proxies and ban-avoidance

X’s trust and safety team has gotten meaningfully better at fingerprinting multi-account operators over the past two years. the mandatory phone verification that rolled out in late 2023, combined with device fingerprinting signals that now track canvas hash, WebGL renderer, audio context, and behavioral timing, means that the “open incognito and make another account” approach stopped working reliably around mid-2024. if you’re running ten or more accounts for growth operations, agency work, airdrop farming, or community management, you need an actual stack.

this guide is written for operators who already understand that running multiple X accounts violates X’s Terms of Service and are making an informed decision to proceed anyway. i’m not here to talk you into or out of it. what i am here to do is explain the infrastructure choices that determine whether you’re flagged in week one or still running clean six months later. the difference between those outcomes is almost always fingerprint hygiene and proxy quality, not posting volume.

by the end of this tutorial you’ll have a working antidetect browser setup, a proxy configuration that gives each account a unique residential IP, a warming protocol, and a monitoring workflow. i’ll also cover what happens when accounts get suspended anyway, because they will sometimes, and what you can actually recover.

what you need

antidetect browser (pick one) - AdsPower - starts at around $9/month for 10 profiles, solid for smaller operations, has a built-in RPA workflow builder - Multilogin - starts at $29/month, more mature fingerprint engine, better for teams - GoLogin - starts at $24/month, good middle ground, decent API

residential proxy provider (pick one) - Bright Data - metered residential starts around $8.40/GB, most reliable pool, good documentation - Smartproxy - $7/GB for residential, simpler dashboard, good enough for most use cases - Oxylabs - enterprise-tier pricing, worth it at 500+ accounts

account sources - self-registered accounts (phone number per account, clean but slow) - aged marketplace accounts (60-day+ aged accounts run $3-15 each depending on follower count and history) - SMS verification service: 5sim or smsactivate, roughly $0.10-0.50 per number depending on country

automation (optional but recommended at scale) - Playwright for scripting browser actions - dedicated X automation tools (TweetAttacksPro, Jarvee for basic posting)

budget floor: you can start a 10-account setup for around $50/month all-in. at 100 accounts expect $300-500/month depending on proxy consumption.

step by step

step 1: set up your antidetect browser

download AdsPower or Multilogin and create a fresh profile for each account slot before you touch any X URL. the profile needs its own:

  • browser fingerprint (the antidetect browser generates this, don’t customize individual fields randomly, use the browser’s built-in generator per profile)
  • timezone matched to the proxy’s exit node geography
  • language settings matched to the same geography
  • webRTC leak prevention enabled

in AdsPower, go to New Profile > Browser Fingerprint and hit “Random” once, then match the timezone to wherever your proxy IP will be exiting. save the profile. do this for every account slot before you assign proxies.

if it breaks: if X immediately flags a new account on first login, the most common cause is timezone/proxy geography mismatch. check that your profile’s system timezone matches the proxy exit country.

step 2: configure residential proxies

each browser profile needs its own dedicated proxy, not a shared rotating endpoint. one IP per account is the rule. residential rotating proxies where the IP changes per session will get you flagged because X sees the same account logging in from different ASNs within minutes.

for Bright Data, set up a “Residential” zone and use sticky sessions with a 24-hour duration. the endpoint format looks like:

zproxy.lum-superproxy.io:22225
username: customer-CUSTOMER_ID-zone-ZONE_NAME-session-ACCOUNT_SLUG-country-SG
password: YOUR_PROXY_PASSWORD

replace ACCOUNT_SLUG with a consistent identifier per account (e.g., acct001, acct002). this makes sure the same account always hits the same exit IP for the session duration.

in AdsPower, paste the proxy details into the profile’s Proxy Settings tab and hit Check Proxy before saving. you want to see the residential IP and its reported location before you ever open X.

if it breaks: if the proxy check fails, verify that your Bright Data zone has residential traffic enabled and that you’re not accidentally using a datacenter endpoint. datacenter IPs are flagged much faster on X.

step 3: source and organize your accounts

for self-registered accounts: create them in batches using your antidetect profiles from day one. never use a phone number twice. buy virtual numbers from smsactivate, select a country matching your proxy geography, complete phone verification, then immediately close the tab and let the account rest for 48 hours before any activity.

for purchased aged accounts: before importing credentials into your antidetect profiles, change the password and recovery email on each account through the browser profile you’ve assigned it. this re-anchors the account’s session to your infrastructure.

keep a spreadsheet or Airtable base with columns: account username, assigned profile ID, assigned proxy session slug, account age, phone number used, current status. you will need this when accounts start going sideways.

if it breaks: if a purchased account immediately locks on first login, the seller’s fingerprint is still on the session. log out completely, clear cookies within the profile (not the whole browser, just cookies), log back in, and complete any 2FA the account prompts.

step 4: warm up each account

X’s behavioral scoring looks at the ratio of actions to account age. a three-day-old account that follows 200 people and posts 10 times a day is a clear signal. warming timelines by account age bucket:

  • days 1-7: profile completion only (bio, avatar, header). no posting. follow 2-5 accounts in a niche relevant to the account’s purpose.
  • days 8-14: like 5-10 posts per day, follow 10-15 accounts, post 1-2 original tweets. engage with replies on at least one thread.
  • days 15-30: scale to normal operational volume gradually. following limit at this stage is roughly 100-150 new follows per day before triggering a temporary restriction.

schedule warming actions at irregular intervals during your target timezone’s waking hours. posting three tweets at exactly 9:00am, 12:00pm, and 3:00pm every day is a behavior flag. add random offsets of 15-45 minutes.

if it breaks: if an account gets a “confirm you’re not a bot” captcha during warming, solve it manually in the antidetect profile, not via OCR automation. a failed captcha on a fresh account during warming usually ends the account.

step 5: build your posting workflow

at 10 accounts you can manage this manually with AdsPower’s profile switcher. at 30+ you need scripted posting. Playwright with the X API v2 endpoints is the cleanest approach, though free-tier API access is heavily rate-limited as of 2025. browser automation via Playwright against the web UI is more reliable for high-volume posting than the API at this tier.

a minimal Playwright posting script:

const { chromium } = require('playwright');

async function postTweet(profileWsUrl, tweetText) {
  const browser = await chromium.connectOverCDP(profileWsUrl);
  const context = browser.contexts()[0];
  const page = context.pages()[0];

  await page.goto('https://x.com/compose/tweet');
  await page.waitForSelector('[data-testid="tweetTextarea_0"]');
  await page.click('[data-testid="tweetTextarea_0"]');
  await page.keyboard.type(tweetText, { delay: Math.floor(Math.random() * 80) + 40 });
  await page.waitForTimeout(1200 + Math.random() * 800);
  await page.click('[data-testid="tweetButtonInline"]');
  await page.waitForTimeout(2000);
  await browser.close();
}

the profileWsUrl comes from AdsPower’s API when you open a profile. the typing delay randomization matters, uniform typing speed is a bot signal.

if it breaks: X periodically changes data-testid selectors. if the selector fails, open the profile manually, inspect the compose box element, and update your selector.

step 6: monitor account health

check each account’s status weekly at minimum. signals that an account is heading toward suspension before the actual ban:

  • “limited visibility” notice on tweets (shadowban)
  • sudden drop in impressions without content change
  • follow actions returning errors even below daily limits
  • CAPTCHA prompts appearing on routine page loads

tools for shadowban checking: shadowban.eu runs free checks. blocktogether.org is useful for detecting coordinated block patterns from anti-spam communities. for proxyscraping.org readers who are also running residential proxy sourcing operations, the proxyscraping.org/blog/ has a good breakdown of how IP reputation scoring works across social platforms, which is directly relevant to why proxy quality determines account health here.

if it breaks: if impressions drop to near zero on a specific account, the account is likely shadowbanned. reduce posting frequency for two weeks and shift content toward original text rather than links or images. shadowbans on X typically lift in 7-21 days without additional action.

step 7: handle bans and appeals

when X suspends an account, you’ll see one of three outcomes:

  1. temporary suspension (usually 12-72 hours): do nothing. don’t appeal, don’t log in repeatedly. let the timer run.
  2. permanent suspension with appeal option: submit an appeal through the in-browser prompt. keep it brief, factual, and don’t mention automation. success rate on appeals is low but nonzero for older accounts.
  3. permanent suspension, no appeal path: the account is gone. rotate in a replacement from your bench, reassign the same proxy session to the new profile.

don’t reuse phone numbers from suspended accounts on new registrations. X’s systems correlate phone numbers across account history.

common pitfalls

using datacenter proxies to save money. datacenter ASNs (AWS, DigitalOcean, Hetzner) are heavily flagged on X. the $0.50/GB you save is not worth the 3x higher ban rate. residential or ISP proxies only.

warming too fast. the most common reason i see operators burn through batches of accounts is impatience during the first two weeks. stick to the warming schedule.

sharing proxy IPs across accounts. even briefly. if two accounts ever appear to log in from the same IP within a short window, X correlates them. the cluster gets flagged together.

inconsistent fingerprints within a profile. some operators manually tweak individual fingerprint fields thinking they’re being clever. random individual overrides often create impossible combinations (e.g., a Chrome 124 UA with a Windows 10 fingerprint reporting a macOS screen resolution). use the antidetect browser’s generator, don’t override individual fields manually.

ignoring the behavioral signals. the technical stack handles fingerprinting, but X also scores engagement patterns. an account that only posts, never reads, never scrolls, and never has any dwell time on content is behaviorally anomalous. your automation needs to simulate reading behavior between actions.

scaling this

10 accounts: manage manually with an antidetect browser. one proxy session per profile. spreadsheet tracking. estimated time: 2-3 hours/week.

100 accounts: you need Playwright or equivalent scripted posting. AdsPower or Multilogin’s API becomes essential. proxy spend rises to $150-300/month depending on your posting volume. assign an account manager to handle warming and ban response. antidetect browser reviews on antidetectreview.org/blog/ are worth reading at this stage to evaluate whether your current browser is scaling cleanly.

1000 accounts: this is a full operations team problem. you need dedicated proxy infrastructure, likely a contract with Bright Data or Oxylabs at volume pricing. your Playwright scripts need error handling, retry logic, and dead-account detection. database-backed account management replaces spreadsheets. ban rate at this scale will average 3-8% per month even with good hygiene, so your pipeline for sourcing and warming replacement accounts needs to be continuous, not reactive.

where to go next

Written by Xavier Fok

disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-05-22.

need infra for this today?