Your Singapore traffic is most likely one rented network
At the end of August, Singapore became the second country by pageviews on one of our sites. No conversions, no interaction, an average session under ten seconds. We took it apart down to the network level, and the whole spike turned out to be one farm renting Tencent address space. Blocking the country is the wrong fix. It shuts out real visitors too. The country is only a guess made by a geo database. The next update may file the same addresses under another country. The datacenter behind them stays the same.
What the logs show
Nine days of our own web server logs, the record of every request the server receives. All of this traffic came from 43.172.0.0/14, a range in Tencent's network AS132203:
- 2,144 requests, including 1,078 page loads and 1,057 tracker calls (the request our tracking script sends to count a pageview)
- 1,451 unique IPs across 24 /24 subnets, that is, 24 blocks of 256 neighbouring addresses
- never more than 6 hits from one IP in all nine days
- referrer empty on 1,073 of the 1,078 page loads
- no CSS, no images, no fonts, ever
- 21 user agent strings (the line in which a browser names itself), all Windows 10, Chrome 103 to 133
- a steady 170 to 230 pages a day, no weekend dip
The pairs are the interesting part. We matched every tracker call with the page load that came before it, within ten seconds.
What we saw: the two IPs differed every time, the median gap was 3 seconds, and the user agent matched in 93% of pairs, so the pairs were real.
What it means: one IP fetches the HTML, another one reports the pageview. A real browser nearly always sends both from the same IP, and usually without such a pause.
Why the IP level shows nothing
Six hits from one IP over nine days trips no ordinary rate limit. At IP level this reads as 1,451 different visitors. At the level of those 256-address blocks it reads as 24 subnets behaving identically.
Our own logs for the same site, counted over one week, said it again:
| Singapore | US | |
|---|---|---|
| Sessions | 827 | 555 |
| Visitors | 824 | 480 |
| Engagement reports | 10 | 488 |
| Bounce rate | 98% | 60% |
| Average duration | 9.6 s | 346 s |
An engagement report is what our tracker sends when someone actually spends time on a page. Ten of them from 827 Singapore sessions means almost nobody there was reading.
The network level
Part of this traffic is visible in the request itself. The rest looks like an ordinary browser, and the only thing that gives it away is the network it arrives from.
That is why a list of datacenters does more than any single signal inside a request. Every network on the internet is registered as an autonomous system (AS): a numbered block of addresses that one provider owns and runs. Renting a server is cheap. Changing your autonomous system means moving to another provider. On 22 September 2026 our list had 27 autonomous systems:
132203 Tencent 45090 Tencent
55960 AWS China 55990 Huawei Cloud
136907 Huawei International 45102 Alibaba US
212238 Datacamp 9009 M247
203020 HostRoyale 207990 HostRoyale
133499 HostRoyale 134450 HostRoyale
18779 EGIHosting 7979 Servers.com
62874 Web2Objects LLC 204646 web2objects GmbH
50077 SYN LTD 55470 Cyfuture India
40676 Psychz Networks 398781 Oculus Networks
202015 HZ Hosting 396319 Oxylabs
39855 Mod Mission Critical 47007 Colocation America
64286 LogicWeb 203346 Proper Support LLP
11798 Ace Data Centers
Six of the 27 are Chinese clouds: Tencent, Huawei, Alibaba and AWS China. That is why the same list also covers the China half of the question. We have measured China too, but we cannot publish those numbers yet. The farm we took apart here rented in Singapore.
How the list was built comes down to one question asked network by network: does anyone arriving from here ever interact with a page at all? Networks where the answer was effectively no went on the list. It is rechecked on a schedule, because the answer changes.
What this post leaves out, and why. We are not publishing the exact checks that catch the part visible in the request, the thresholds behind the list, or the order they run in. Whoever operates this farm reads the same forum threads about bot traffic we do, and a precise recipe is a to-do list for their next release: add one header, randomise one delay, and the article that helped you costs you the detection. So what is here is the part that stays true after they have read it. The networks are named, because a datacenter cannot quietly stop being a datacenter. Our two mistakes are described in full: blocking all hosting and trusting an old geo database. Knowing them helps you avoid them, and it helps the farm with nothing.
Don't block all hosting
The obvious move, blocking hosting as a class, is expensive. Over 4.5 days across five of our own sites we counted 3,939 pageviews. Hosting networks brought 241 of them, from 142 identities. An identity here is one IP address on one site, the closest we get to a visitor without cookies. 92 of those identities spent some time on the page.
Those 92 are 10% of all 924 identities with any engagement in that window. A blanket hosting block would quietly delete one real person in ten from your reports, and you would never see which ones. Datacenters carry corporate proxies, VPNs, Cloudflare WARP and iCloud Private Relay.
We made two exceptions by hand:
- Tier-1 transit, the backbone carriers that move other providers' traffic, stays off the list even when the numbers look bad. GTT AS3257 met our criteria, but those IPs belong to somebody else's customers.
- Apple Private Relay egress ranges, the addresses Relay sends its users' traffic out from, sit in a separate allowlist, because formally they are not residential either.
One more thing that cost us time: an older geo database placed that same Tencent range in Japan. Check the date on yours before you conclude anything about a country. If your site runs on Statable, this list already works for you. Pageviews from these networks never reach your reports, and there is nothing to set up. If you know specific addresses you want to keep out, add them to your blocklist. It takes IP addresses, hostnames and countries.
Where we draw the line
The tempting path is to recognise a visitor from dozens of signals read out of their device. We did not take it. Article 5(3) of ePrivacy covers reading information from a device, not only storing it there. So reading canvas, WebGL or the font list without consent is a problem at the moment of reading, whatever happens to the result afterwards. Our checks run on our own servers, not in the visitor's browser. They look at what arrives with every request, at behaviour over time, and at the network. To tell visitors apart we use the IP address and the browser's user agent, which every request carries anyway, turned into a hash that changes every day. Neither of them is saved in your analytics. So our cookieless analytics reads nothing from the device to recognise a visitor, and that is a fair question to put to every tool on your shortlist, including the alternatives we measured.
Limits of this study
- one of our sites over nine days, and five of our sites over 4.5 days
- logs rotate after 10 days, so we cannot look further back
- "behaves like a person" here means engagement time above zero. It is an approximation: someone who leaves at once has none either
- the list drifts. Datacamp and Huawei International sit close to the cut because both also host VPNs, so it has to be rechecked regularly
Ready to take control of your web analytics? Try Statable free for 30 days. No credit card required, full feature access, built for GDPR. Start your free trial or view a live demo.

