Why Blocking Hits One User and Not Another
Two people get the same setup. It works for one and not the other. Both are in the same city, sometimes the same flat — on different operators. The difference is not random: restrictions apply not to a service as a whole but to a specific path between a specific pair of points, and two people take different paths.
This is a steady source of confusion and unproductive arguments in support. The cause is neither luck nor setup quality: modern filtering has no single point and no single verdict for everyone.
Filtering is distributed, not centralised#
The first thing to understand: filtering equipment does not sit on one large national gateway.
Measurements published by researchers in 2022 showed the opposite picture: equipment installed close to subscriber networks, for most measured points within the first few network hops from the user. The study covered more than a million endpoints across hundreds of autonomous systems.
Policy is centralised while enforcement is distributed. Between “the policy is uniform” and “the behaviour is uniform” lies a gap:
- different operators update equipment at different times;
- versions, settings and load differ between operators;
- some smaller operators sit behind an upstream provider’s filter rather than their own.
The direct consequence: a neighbour in the same building on a different operator lives in a different network reality.
What does the filtering actually count?#
The second source of divergence is that accounting is not done per service. Accounting is per path and per connection, so two people with identical setups fall under different rules.
Restriction mechanisms work on pairs and flows:
| What is counted | What it means for you |
|---|---|
| The pair “your address — destination address” | your neighbour has a different address, so a different counter |
| An individual connection | one connection can be restricted while another is not |
| The name declared when opening a secure connection | one name can behave differently from another |
The key point: counters are attached to you, not to the service. Your activity over the last few minutes shapes what happens to your next connection. Another person’s history is their own.
Walkthrough: two people in the same flat#
The most common argument in support. Break it into layers.
User A User B
operator "Alpha" operator "Beta"
│ │
▼ ▼
Alpha's filter Beta's filter
version 2026-05 version 2026-08 ← different versions
│ │
▼ ▼
address 203.0.113.17 address 198.51.100.4 ← different counters
own history own history
│ │
└──────────────┬──────────────────────┘
▼
the same server
Three independent differences along the path, none of them related to configuration:
| Layer | For A | For B |
|---|---|---|
| Equipment | May build | August build |
| External address | own | own |
| Activity history | own | own |
The conclusion that saves support time: “it works for him” is not a refutation of your problem. It is an observation under different conditions. A refutation would be “it works for another person on the same operator, with the same address, at the same time” — and that comparison is almost never available.
A numeric example: why mobile behaves differently#
The shared-address mechanics of mobile operators explain most of the complaints.
| Home internet | Mobile | |
|---|---|---|
| Subscribers per external address | 1 | tens to hundreds |
| Whose activity lands in the counter | yours | yours plus every neighbour’s |
| How the concurrency threshold fills | through your actions | in the background, without you |
Hence an effect that is hard to explain to a user: you did nothing and the limit is already spent. On a mobile connection the counter keyed to the address is filled by strangers’ activity.
The practical consequence: if mobile performs worse than home under otherwise equal conditions, that is expected rather than a sign of a fault.
Why “it broke for an hour and then fixed itself”#
A common and puzzling scenario.
Some restrictions are a temporary state rather than a permanent rule: once triggered they hold for a while and then lift on their own. While active, connection attempts look like total failure.
The practical conclusion is counter-intuitive and therefore worth stating: persistent retrying during that window makes things worse. Every new attempt reinforces the pattern that produced the state. A pause works better than cycling through servers.
Why mobile behaves differently#
Mobile networks differ from home connections in more than speed:
A shared external address. On mobile operators hundreds of subscribers share one external address. Counters keyed to that address fill up with other people’s activity — you pay for the behaviour of your neighbours behind the same address translation.
Different routes and different equipment. The mobile segment is often updated separately from the fixed one.
Address changes in motion. Switching between towers can change the external address, clearing some states and creating others.
So “it works on mobile but not at home” is not a paradox but a different set of conditions. And the reverse.
What this means for diagnosis#
Several practical rules follow.
Only comparable conditions are worth comparing. “It works for my friend” is not an argument if the friend is on another operator. Those are two separate observations, not a confirmation and a refutation of one.
One failure is not a conclusion. The state is temporary and the lists move. Repeat the observation later before writing a channel off.
Test on two operators if you can. Home and mobile give two independent vantage points. Matching results point at the channel; diverging results point at a property of one network.
Do not cycle through everything. Bulk connection attempts worsen the state. One server, one attempt, then wait.
What almost never happens#
Worth naming the inverse — theories that come up constantly in support and are almost always wrong.
“I am being blocked personally.” The mechanisms work on traits and counters, not on lists of people. The feeling of personal treatment comes from counters being attached to your address.
“It is my device.” A device affects what a connection looks like, but not which equipment it passes through. Swapping phones on the same network usually changes nothing.
“My ISP is throttling me deliberately.” Far more often what is observed is a general mechanism rather than a targeted decision. Easy to test: if another subscriber on the same operator sees the same thing, it is not about you.
Conclusion#
The difference between two users comes down to three things: different equipment on the path, different counters keyed to the address, and a different recent activity history.
None of them relates to setup quality. Which is why replacing “why does it work for him” with “how do the conditions differ” is the more productive question — and usually the one that has an answer.
Terms#
- Distributed filtering - a model where rules are applied at many independent points rather than one centre.
- Vantage point - the specific combination of carrier, region and network segment a measurement is taken from.
- Counter state - accumulated statistics for a connection or address that make a restriction engage later rather than immediately.
FAQ#
Why does it work for my neighbour and not for me?#
Because you take different paths. The restriction applies to the path between a specific pair of points, not to the service as a whole.
Why does changing carrier help?#
The carrier determines the network segment and the set of rules applied. A different carrier means a different path and different rules.
Why did it break for an hour and then fix itself?#
Some restrictions engage on accumulated state and lift when that state expires, with no action on your part.
Further reading#
- Your VPN Check Says Timeout but the Connection Works
- Whitelists: What They Are and Why They Change
- Measuring Blocking Correctly
- Walk the route from setup to diagnosis in the GigaTap VPN guides.
- Pick your next step with the VPN start helper.
- Device-specific profile import lives in the client setup hub.