Zen Cart Logo
Forums / General Questions / abnormal visitor numbers

abnormal visitor numbers

Views: 249

Results 1 to 6 of 6
6 Jul 2026, 8:22 PM
#1
cefyn avatar

cefyn

New Zenner

Join Date:
May 2007
Posts:
87
Plugin Contributions:
1

abnormal visitor numbers

I have a site running 1.5.7b. on a shared hosting plan. s p a r x b a n g o r . c o . uk It is acting as a showroom only for a small shop in North Wales, UK, and is only there for local searches. It is getting an abnormal amount of traffic. It got over a million visits in March 2026, which was using up resources and making the site inaccessible for legitimate users. I opened a cloudflare account, and blocked the worst countries, but even so, after dipping for a while, visits have spiked again today.
I don’t understand what these visitors are doing. They just land on a product page and sit there for about 10 minutes. My admin/who’s online showed 800 visitors earlier today, and they’re all just sitting there. Cloudflare is blocking AI training bots, and the worst offending countries, but today, even with Cloudflare, my resource limits are being breached.
Has anyone got any idea what the point is of all these visits? And does anyone have any idea of what I could do to stop them?

7 Jul 2026, 8:01 AM
#2
shop_suey avatar

shop_suey

Zen Follower

Join Date:
Feb 2014
Location:
Germany
Posts:
375
Plugin Contributions:
0

Re: abnormal visitor numbers

Your shop is super slow. It's only theoretically usable.

I had those scammers in my shop, too.
30.000 on one day ...
Just sitting, scraping, with "bad" urls.
99,5% of the web spammers came from the US, Argentina, Brazil, China, Russia and Vietnam.
All these countries I definitely don't deliver to.

  1. You could try AbuseIPDB.
    There is a plugin for zen cart to use that API service.
    But that will let them still pass to your shop and forbids at a later time.

  2. You could use GEO IP.
    You need to install an Apache module and configure it.
    Probably not possible for your hosting solution.

  3. If you deliver to the UK only you could think of using Whitelisting for IP ranges via htaccess
    That needs frequent controlling but with this method you get control back again.
    And there's no plugin installation / updates / no registrations / no API calls and so on

I deliver to Germany only and I additionally opened the network to various western, northern and southern EU. Just for traffic and branding.
When I see there's access from cloud-server / vservers e.g. from OVH I refine the IP range.
It's unlikely that a human customer is using a vserver IP. Customers use IPs from their ISP. Bots use vserver IPs.
One point is VPN. I'm not able to handle it.
But from my point of view: if anyone needs to hide it might not be my wish to deal with this person.

10 Jul 2026, 8:57 PM
#3
cefyn avatar

cefyn

New Zenner

Join Date:
May 2007
Posts:
87
Plugin Contributions:
1

Re: abnormal visitor numbers

Thank you for your reply. I have had to resort to using under attack mode in Cloudflare, which has pretty well stopped all traffic. I need to make sure now that I have it setup to allow the traffic I do want to come through. I need Googlebot to read the site as a lot of business comes from being found in the Google search for local fancy dress shops.

11 Jul 2026, 11:05 AM
#4
marcopolo avatar

marcopolo

Totally Zenned

Join Date:
May 2008
Location:
United States
Posts:
516
Plugin Contributions:
2

Re: abnormal visitor numbers

cefyn:

Thank you for your reply. I have had to resort to using under attack mode in Cloudflare, which has pretty well stopped all traffic. I need to make sure now that I have it setup to allow the traffic I do want to come through. I need Googlebot to read the site as a lot of business comes from being found in the Google search for local fancy dress shops.

Re: abnormal visitor numbers

I've been fighting what I believe is the same thing on my own store, and part of what looks like a traffic problem may actually be an identity problem. It's worth checking before you spend more time blocking IPs and countries.

Zen Cart core (1.5.x through current 2.2.x) overwrites $_SERVER['REMOTE_ADDR'] on every storefront page load with the result of zen_get_ip_address() — and that function trusts a set of client-suppliable request headers unconditionally: X-Forwarded-For, Client-IP, X-Forwarded, X-Cluster-Client-IP, Forwarded-For, Forwarded, CF-Connecting-IP. There is no check that a proxy you actually trust sent them. Any bot can put whatever it wants in those headers, and Zen Cart will believe it.

The consequences match your symptoms almost exactly:

  1. whos_online inflation. whos_online counts "visitors" by that spoofable IP. A small number of bots rotating forged headers looks like hundreds of distinct visitors sitting on product pages. Your "800 visitors" figure may be a handful of machines wearing 800 masks.

  2. IP blocking becomes whack-a-mole. Every IP you block, the bot just forges a new one on the next request. I watched bots on my store impersonate 127.0.0.1 and private ranges — addresses that can't possibly be real clients.

  3. Country blocking leaks. Cloudflare's geo-block works on the true edge IP, so it does help — but only for traffic that actually goes through Cloudflare. If your origin server accepts connections from anyone (not just Cloudflare's published IP ranges), bots that have found your origin IP bypass Cloudflare entirely and spoof headers straight at Zen Cart. Given that your resource limits are being breached despite Cloudflare blocking, this is worth ruling out — ask your host whether the origin can be restricted to Cloudflare's ranges.

  4. Even through Cloudflare, X-Forwarded-For isn't safe. Cloudflare appends the real client IP to any X-Forwarded-For the client sends — it doesn't replace it. Zen Cart reads XFF and can end up using the forged first value. The only header Cloudflare sets authoritatively is CF-Connecting-IP.

What I did on my server made a dramatic difference: since nothing proxies in front of it, none of those headers have a legitimate sender, so I strip them all at Apache before PHP ever sees them:

```php
<IfModule mod_headers.c>
    RequestHeader unset X-Forwarded-For
    RequestHeader unset Client-IP
    RequestHeader unset X-Forwarded
    RequestHeader unset X-Cluster-Client-IP
    RequestHeader unset Forwarded-For
    RequestHeader unset Forwarded
    RequestHeader unset CF-Connecting-IP
</IfModule>

Overnight, my "unique visitor" counts collapsed to something believable, and per-IP blocking started actually sticking.

**Your setup needs one important adjustment:** you're behind Cloudflare, so do NOT strip `CF-Connecting-IP` — that's your real client IP. Strip the other six (this works in `.htaccess` on most shared hosts if mod_headers is enabled), lock your origin to Cloudflare's IP ranges if your host allows it, and make sure your stack derives the client IP from `CF-Connecting-IP` (Cloudflare's mod_remoteip guidance covers this, or your host may already handle it).

None of this reduces raw request volume by itself — Under Attack mode and Cloudflare's bot rules are still the right tool for that, and a WAF rule allowing verified Googlebot (Cloudflare has a built-in "known bots" category) will solve your indexing concern. But until the header trust is fixed, every visitor count, every IP block, and every whos_online report on a Zen Cart store is potentially fiction. I'd argue this deserves attention in core: a spoofed-header problem quietly distorts what every shop owner in this situation is looking at while they try to diagnose it.
16 Jul 2026, 8:51 AM
#5
cefyn avatar

cefyn

New Zenner

Join Date:
May 2007
Posts:
87
Plugin Contributions:
1

Re: abnormal visitor numbers

Thanks, I’ll look into all of this. I’ve had to look at a lot of things with this site. It’s been neglected for a while, and because of this and various other issues I’ve upgraded it on a local server to zen cart 2.2.2. I’m going to put that on a new host, and see how it transpires.

21 Jul 2026, 7:15 PM
#6
drbyte avatar

drbyte

Sensei

Join Date:
Jan 2004
Posts:
63,513
Plugin Contributions:
176

Re: abnormal visitor numbers

The root cause here is that older Zen Carts trust those client-supplied IP headers (X-Forwarded-For, Client-IP, etc.) unconditionally, so a bot rotating forged headers looks like hundreds of distinct visitors, inflating your active-visitor stats and slipping past any IP-based blocks you've set ... which drives up exactly the load you were trying to block.

This PR fixes that: https://github.com/zencart/zencart/pull/7931 : forwarded headers are only honored when the request genuinely comes from a proxy you've listed in a new TRUSTED_PROXIES setting.

With this change, by default (even if you don't set TRUSTED_PROXIES or leave it as an empty array list) all forged headers are ignored, so most sites are protected with no configuration by applying this patch.

If you're behind Cloudflare, set TRUSTED_PROXIES to Cloudflare's published IP ranges (you can find them in https://www.cloudflare.com/ips/) in your actual configure.php file(s) so the real visitor IP is still resolved correctly. Note the comments in the dist-configure.php files for correct syntax.
For another proxy/load-balancer other than Cloudflare, use their trusted edge IP addresses instead.
If you're NOT behind a proxy/CDN/load-balancer, you don't need to define TRUSTED_PROXIES at all, and this patch will give you better protection against forged headers already.

This patch also makes the manual .htaccess header-stripping workaround unnecessary.

This ships in v2.3.0 (releasing very soon), and can be backported to current 2.x installs quite easily by hand (2.2.2 is very easy, but patching onto 2.1 and 2.0 must be done by hand, not automated).

(Only the /admin/* and /includes/* files need patching. The not_for_release and zc_install dirs aren't relevant for a live site.)
And you don't need to patch the dist-configure.php files: you just need to copy the new define to your own configure.php files ... and only if your site is behind a proxy. If you don't copy the define, you'll still get protection by applying the patch.

/cc @marcopolo
/cc @cefyn