Proxy field notes Response codes Pool sizing Choosing an address

Shadow ban check: the account is alive and nobody sees it

The account works. Posts publish, comments open, the profile answers on a direct link, support says everything is in order. Reach sits at zero.

I spent five weeks on this state across nine profiles I run for a furniture workshop, and the whole time went into one question: which of the plausible causes was the real one. Below is every hypothesis I held, the measurement that settled it, and the numbers my own log produced. The order matters, because a hypothesis tested out of sequence gives an answer you cannot use.

The numbers I had before any hypothesis existed

I keep my own log alongside the platform dashboard. Every post gets a row: profile, publishing hour, reach at 24 hours, reach at 72 hours, saves, profile visits. Two years of that habit gave me the one thing this investigation needed, a baseline that predates the trouble.

For the 14 days before the drop, median reach per post across the main profile was 4180 at 72 hours. I work with the median throughout. An average gets dragged around by one lucky post, and during a collapse it hides the shape of what happened.

Then one Tuesday the number was 310. Wednesday, 240. By Sunday the seven-day median stood at 260, a fall of 94 percent, with publishing volume unchanged at 3 posts a day.

Everything else looked normal. Followers commented under new posts within minutes. Likes arrived, roughly 40 per post, all from accounts already subscribed. Profile visits from search dropped to single digits. The pattern pointed somewhere specific: distribution to people who do not follow me had stopped, and distribution to existing followers kept running.

That distinction is the first measurement worth taking. Split reach into followers and non-followers before you touch anything else. If both fell, you are looking at one class of causes. If only the non-follower half fell, you are looking at a different class, and half the hypotheses below drop out on day one.

Mine was the second case. Follower reach held at 92 percent of baseline. Non-follower reach went from 3450 to 94.

sqlite3 reach.db "SELECT profile, date(ts,'unixepoch') d,
       count(*) posts,
       CAST(AVG(r72) AS INT) mean_r72
  FROM posts WHERE ts > strftime('%s','now','-21 days')
  GROUP BY profile, d ORDER BY d DESC;"   # nightly export, one row per post

Hypothesis one: the platform reshuffled ranking for everyone

This is where most people stop, because it explains the drop and requires no action. It also happens to be testable in an afternoon.

I keep a watch list of 6 accounts in the same niche, similar follower counts, similar posting rhythm. Three belong to workshops I know personally, three are competitors whose public numbers I record weekly. A ranking change hits a segment, so a segment-wide move shows up across all of them at once.

Group	Median reach before	Median reach during my collapse	Change
My main profile	4180	260	down 94 percent
3 profiles of mine on separate exits	3720	3650	down 2 percent
3 competitor accounts, same niche	3600	3480	down 3 percent
3 workshop accounts I track directly	5100	4890	down 4 percent

A platform-wide reshuffle produces the second, third and fourth rows. It does not produce the first row on its own. A 2 to 4 percent drift across nine outside accounts is ordinary weekly noise, and I have the same drift recorded through quiet months.

So hypothesis one closed on the first evening. I want to stress how cheap that was: one table, numbers I already collected, no changes to any account. Every hour I would have spent rewriting captions on a ranking theory got saved right there.

One caution about control accounts. Pick them before you need them. Accounts chosen during a crisis get chosen to confirm what you already suspect, and I have done exactly that in an earlier round, picking three profiles that happened to be falling and calling it proof.

Hypothesis two: my content simply got weaker

Reasonable and hard to argue with, since content quality has no dial to read. The way around that is a donor test: publish identical material from two accounts and compare.

I took a video that had cleared 6200 reach seven weeks earlier, exported the same file, wrote the same caption word for word, and published it at the same hour from two places. The main profile has 12 900 followers. The donor account, run for a different product line, has 11 400.

Donor: 3940 at 72 hours. Main profile: 240.

The same file, the same caption, the same minute of the day, one account distributing normally and one flat. Content left the list of causes that evening. I ran the test twice more over the following week with different material, and the gap held at a factor of 14 and 17.

There is a trap worth naming here. The donor account has to be genuinely separate: its own address, its own browser profile, its own history. A donor sharing an exit with the restricted account will reproduce the restricted account's numbers, and you will read that as proof the content is weak. My first donor attempt did precisely that, returning 380, and it took me two days to notice both profiles were leaving through one office router.

Hypothesis three: I moved to the wrong publishing hour

Timing theories are popular because the fix feels free. Measuring one properly costs 8 days and a bit of discipline.

I fixed 4 windows: 07:40, 12:10, 18:30 and 22:15. Over 8 days that gave 32 posts, 8 in each window, alternating so no window got a run of similar material.

Window	Posts	Median reach at 72h	Best single post
07:40	8	275	340
12:10	8	290	415
18:30	8	260	355
22:15	8	310	460

Every window sat inside a band of 50, against a baseline of 4180. The spread between the worst and best hour is noise at this scale. Publishing time was carrying none of the loss, and I dropped the hypothesis with the numbers to back it.

I keep the table because it also refutes a softer version of the same idea, the one where a platform "punishes" a changed schedule. My schedule changed four times inside those 8 days and the median never moved.

Hypothesis four: the account carries a shadow restriction

By this point three causes were gone, so I moved to the one nobody can confirm from inside the account. Platforms do not send a notice for this state. The account stays open, publishing works, and visibility to people outside your follower list gets reduced to nothing.

The measurements are all external, and every one needs a device that is not logged into the account. I use a spare phone on mobile data.

Exact handle search, logged out: the profile appeared in 1 attempt out of 5. Before the collapse it was the first result every time, and I had checked it often enough to know.

Hashtag pages: I published with 12 tags and checked every tag page from the logged-out phone within 20 minutes. The post appeared on 0 of them, in either the recent feed or the top feed. A colleague published to the same tags in the same window and showed up on 11.

Mention rendering: I asked two colleagues to mention the handle in a post. On their side the mention stayed as plain text with no link on one platform, and on the other it linked correctly. Mixed result, and a mixed result is still data.

Direct link: everything works. The profile opens, the posts open, comments post and stay visible.

Comment visibility from outside: my comments under other accounts' posts were absent when the same posts were opened logged out, on 7 checks out of 9.

That combination is the signature. A ranking drop lowers your numbers and leaves you visible in search, in tag pages and in comment threads. A restriction leaves the account fully functional for anyone holding the direct link and removes it from every surface where new people would find it.

Marker	Under a ranking drop	Under a shadow restriction	What mine did
Follower reach	falls with the rest	holds near baseline	held at 92 percent
Non-follower reach	falls by 20 to 50 percent	falls to a few percent	3450 to 94
Handle search, logged out	profile still first	profile missing or buried	1 hit in 5
Hashtag pages	post present, ranked lower	post absent from every tag	0 of 12 tags
Comments seen logged out	visible	filtered out	absent on 7 of 9
Donor account, same file	falls too	distributes normally	3940 against 240

Six markers, six answers pointing the same way. That is the moment the question changed from "is something wrong" to "which signal made the platform treat this account as a problem".

Hypothesis five: the exit address carries a history

An account is judged by what the platform can measure about it, and the connection point sits at the top of that list. Mine had a history I had never checked.

Three of the nine profiles left through one office router. That address had been in use for years by everyone in the room, and at some earlier point somebody there had worked with accounts bought from a reseller. The platform sees a connection point, counts what has happened behind it, and applies the count to whoever arrives next.

I ran the swap as a single-variable test. New exit, same device, same browser profile, same content plan, same hours. Nothing else moved for 5 days.

Day 1 after the swap: 410. Day 2: 720. Day 3: 1870. Day 5: 3110. Three weeks later the median settled at 4020, which is 96 percent of the original baseline.

The recovery curve matters as much as the endpoint. A restriction lifts gradually, over days, as the platform re-measures an account from a connection point with no accumulated history. An instant jump back to baseline would have suggested something else entirely, most likely a temporary distribution fault on the platform side.

For the swap I used private addresses nobody else routes through, one per profile, so the history behind each connection point belongs to that profile alone. That is the property doing the work here. A connection point with a known owner and a known set of accounts behind it is a connection point the platform can judge on its own merits.

Address type mattered too. Social profiles need weeks of stability, so I take a monthly rental for every working exit and pin it for the life of the profile. An account that connects from a new place every day generates its own set of checks, and I have collected those checks personally on an earlier project.

Hypothesis six: the profiles are tied to each other

The swap fixed one profile. Two others were still flat, and they were exactly the two that had shared the office router with it.

That is a second, separate mechanism, and it deserves its own measurement. Profiles connected through shared signals get judged as a group. A restriction landing on one of them spreads to the others in days, and my log shows the spread precisely: the first profile lost reach on a Tuesday, the second on the following Sunday, the third four days after that. The remaining six, each on its own address, never moved.

Here is what I checked on the tied trio, in the order that produced answers fastest.

Exit point: shared, confirmed by opening an address detection page from each profile window and comparing the result.

Browser fingerprint: identical. All three ran in one browser, in separate tabs, on one machine. Canvas, fonts, screen metrics and timezone matched perfectly, because they were literally the same browser.

Storage and cookies: shared, since separate tabs share a profile directory.

Recovery time after separation: 6 days for the second profile, 9 for the third, both returning to within 10 percent of their own baselines.

I moved every profile into an antidetect browser with isolated profiles, one profile per account, each with its own parameter set and its own storage. The address goes into the profile settings before the first visit, so the browser reaches the platform through that exit and no other. Where I work through a setup built around Dolphin, the address field sits in the profile card itself, which makes the pinning a part of profile creation.

For the addresses themselves I keep a dedicated IPv4 address for each profile. Nine profiles, nine addresses, plus two held spare for replacements. The spare pair has already earned its place twice.

Hypothesis seven: the exit leaks the original address

This one appeared after the swap, when the third profile stayed flat for two days on a brand new address. My assumption had been that a new exit means a new connection point. The headers said otherwise.

I check every address before a profile touches it, and I had skipped that step in a hurry.

curl -s -x "http://user:pass@$ADDR:$PORT" https://ifconfig.me/all \
  | grep -Ei 'ip_addr|forwarded|via|x-real-ip'   # checked before a profile goes near it

The output carried a forwarded header holding my office address. From the platform's side the connection still came from the place it had already judged, and the three profiles stayed grouped exactly as before. Two days of measurement went into a question one command would have answered in 4 seconds.

I now work through anonymous exits that pass no origin headers and run the check twice: once when the address is issued, once a week during ordinary work. The weekly repeat is there because settings drift. An antidetect update reset a profile's address field on me once, and the profile spent half a day connecting from the office before my Monday check caught it.

How I build control measurements so the numbers mean something

Five weeks taught me more about measurement discipline than about platforms, and this part transfers to any account problem.

One variable per run. The swap test changed the exit and froze everything else: same device, same content plan, same hours, same posting volume. When two things move together, the result explains nothing, and I have wasted whole weeks that way.

A baseline that predates the trouble. Fourteen days of median reach recorded before anything went wrong is worth more than any analysis performed afterwards. Start the log today even if nothing is wrong today.

The median, always. My reach distribution has a long tail, so one viral post pulls an average up by 30 percent and hides a collapse underneath it.

A donor account that shares nothing. Its own address, its own browser profile, its own history. A donor that shares any of those returns the restricted account's numbers and sends you chasing content quality for a fortnight.

External observation, from a device that never touched the account. Logged-out search from mobile data, hashtag pages, comment visibility. Everything the account shows you from inside is the view the platform gives to the account owner, and that view stays reassuring the entire time.

Enough runs to beat noise. Eight posts per window in the timing test, three repeats of the donor test, 5 days minimum on the exit swap. Single observations produce confident wrong conclusions.

Where the numbers landed and what each stage cost

The full sequence took 34 days from the first flat Tuesday to a stable median.

Stage	Days spent	Median reach at the end	What it settled
Baseline already on file	0	4180	gave every later number a reference
Control group comparison	1	260	ranking reshuffle ruled out
Donor test, 3 repeats	6	240 against 3940	content quality ruled out
Window rotation, 32 posts	8	285	publishing hour ruled out
External visibility checks	1	unchanged	restriction confirmed on 6 markers
Exit swap, single variable	5	3110	exit history identified as the cause
Header verification	1	1440 to 3020	leak found on the third profile
Separation of the tied trio	12	4020	grouping through shared signals closed

Two numbers stand out for me. The first is 1 day, the time the control group comparison took, and the point where the whole investigation should have started. The second is 8 days on the timing hypothesis, which produced a table proving a negative, and I would run it again in the same position, because the alternative is a theory nobody ever tested sitting in the back of your head for months.

The nine profiles now run at a combined median of 4020 to 5240 depending on the account, all above their own pre-collapse baselines. Each one has its own exit, its own browser profile, its own storage. When one of them collects a restriction in the future, and one of them will, the measurements above will run against that profile alone, and the other eight will keep working while I sort it out.

That is the practical value of separation. It turns an account problem into a single account's problem, and it turns diagnosis from guesswork into six hours of measurement with a table at the end.

If the build itself interests you more than the diagnosis, I wrote it up separately: rotating proxies covers the profile-per-account build, and buy a proxy server for the job you actually shows the same linking mechanism producing hard blocks where mine produced quiet ones.

The one part I would put in place before anything goes wrong is separation at the profile level, and a separate antidetect profile for every account is where that starts, with its own pinned exit behind it.