Crazy amount of guests

[Alvin63]

I wouldn't assume it isn't working just from Claude's interpretation of the logs yet.

The definitive test is the direct-origin test after the .htaccess rule has been enabled.

Run this again:

curl.exe -I --resolve www.yourforum.com:443:YOUR_ORIGIN_IP https://www.yourforum.com/

If you now get:

HTTP/1.1 403 Forbidden

then it is working correctly, regardless of what Claude thinks it sees in the access log.

The fact that your site is still working normally is actually encouraging, because it means requests coming through Cloudflare are arriving with the correct header and are being accepted by .htaccess.

Copying the secret via Word/Notepad shouldn't normally matter, although hidden whitespace or a strange character could theoretically cause trouble. But if there were a mismatch between the Cloudflare secret and the .htaccess secret, your normal site should now be returning 403 as well.

So I would do the direct-origin curl test first before changing anything else.

If it returns 403, leave the configuration alone.

If it returns 200, then we can look at why the .htaccess rule isn't being enforced on your server.

Thanks. Well as I managed to block myself briefly last night while blocking some ASN numbers (quickly recitifed!) I replaced the .htaccess with the original as I wasn't quite sure what had blocked me in that moment. I will manually re-type the header and code in notepad and try again later today However it wasn't that, I had just blocked the ASN for my IP which was not where I expected it to be!

The .htaccess could well have been working and nothing going to the origin.

As for blocking myself - my internet is Starlink and it seems they are in Guyana! (Edit there is also a Starlink in Myanmar in case anyone is thinking of blocking Myanmar as it might also contain UK IP's). Things had improved with Cloudflare rules at the front - challenging for whats new, search and members, but got frustrated that I was still getting about 1200 to 1800 at night and 800 to 1000 during the day. So last night I went through the IP's in the guest list from countries that I wouldn't usually have members from, looked up the IP on ipinfo.io which shows the ASN number and blocked the ASN. I did that for maybe 12 to 15 ASN's in various countries like Kuwait, Thailand, Philippines, Malaysia, China, and various others including 2 or 3 south american ones. The last one I did was Guyana - should have thought twice when it said something about Space centre rather than Telecommunications companies as all the others were. But that was easily undone.

So the numbers quickly went down to 500 to 600 last night and 300 today. So I'm having a breather. Most of them now are from the USA - so they've probably migrated to residential proxies there. However I was loathe to put a managed challenge on the USA, where I have members, so did the ASN blocking on Eastern countries instead.

I then had the unpleasant thought that I might have blocked a load of people using Starlink if Starlink has IP's in other countries, but ran the blocked ASN's through Google AI (unreliable I know) who said none of them were Starlink ones - only the Guyana one.

The China IP's in the guest list shouldn't have been there at all because a) China is blocked as a country b) the range of ISN's for those particular China Networks were already blocked. But looking up the individual IP's, they had different ASN numbers. The China business could be endless because they apparently have many many ASN's. Haven't checked if they have gone or not yet.

I wasn't happy blocking complete communications networks in some of those countries, because although it's rare my site gets a member from them, I like to think it's an option and there has occasionally been the odd one from South America or even the Philippines. So I'm kind of annoyed about this whole residential proxy business affecting ordinary people.

@puterfixer thanks that is very helpful

One question - looking at the guest list - where (thanks to the digital point cloudflare app) it shows the IP's with country name and flag - is there actually a way to find a list of guests without scrolling through the guest list? Eg in Xenforo or on Cloudflare? It would have been easier to have a more condensed list, and then sort them alphabetically.

I remember a time when the only thing that bugged me was too many incidences of Amazon.bot in the Robots list! This is something else.

 

[Alvin63]

Well one confusion solved. My country blocking of China was set up wrong with AND instead of OR. I had Mexico blocked (which worked) but CHINA didn't seem to be working, yet blocking China ASN's was working. It's because I had Mexico AND China and the rule should have been OR China. So changed that.

 

[puterfixer]

Accidentally cutting your own access from a system is part of the initiation ritual for becoming a sysadmin Teaches two things: 1) double and triple checking your actions, and 2) never starting a change without having a working way to roll back.

 

[smallwheels]

Most of them now are from the USA - so they've probably migrated to data centres there. However I was loathe to put a managed challenge on the USA, where I have members, so did the ASN blocking on Eastern countries instead.

The US is an absolute hotspot of bots, clearly number one when you already blocked countries like China, Brazil and Argentina. There are basically three clusters of bots coming from there:

1. The common search engines like Google and Bing (that you typically would not like to block)
2. all sorts of bots between unwanted, useless and annoying (including loads of scrapers) from data centers in the US. The good thing is: You can basically block all data center ASNs w/o harm - forums are for humans and humans typically don't use data centers for surfing (VPNs, a few company proxies and company ASNs excluded). There is a very long list of US-based ASNs that you can safely block completely.
3. resident proxies that come through DSL/Dialup/Cable networks. These are a bit of a bummer if you do have genuine users from the US as these are loads. It seems that everyone in the US and his uncle have installed bot/proxy software on their computer/device/TV-stick/Router, knowingly or unknowingly. So blocking those networks would solve a problem, however, it would also kill your user base there. So challenging is the way to go and - as many sellers of resident proxies claim that CF challenges would be no issue for them - possibly bot guard on top of that.

 

[smallwheels]

Accidentally cutting your own access from a system is part of the initiation ritual for becoming a sysadmin Teaches two things: 1) double and triple checking your actions, and 2) never starting a change without having a working way to roll back.

3. always have an alternative backdoor to use in case of things go airborne.

 

[Alvin63]

Just a tip for anyone else blocking ASN's in various countries - assuming this hasn't already been mentioned before.

Starlink's main global ASN is 14593 - it could show up in various countries (including Guyana and Myanmar). Also 397763 and 53348.

So Starlink Whitelist is those three.

Some that show up are for Mobile networks like Vodafone (India) 38266 and Orange (Tunisia) 37492 so I think it's important not to block those ASN's as maybe they could affect globally as well?

 

[Alvin63]

The US is an absolute hotspot of bots, clearly number one when you already blocked countries like China, Brazil and Argentina. There are basically three clusters of bots coming from there:

1. The common search engines like Google and Bing (that you typically would not like to block)
2. all sorts of bots between unwanted, useless and annoying (including loads of scrapers) from data centers in the US. The good thing is: You can basically block all data center ASNs w/o harm - forums are for humans and humans typically don't use data centers for surfing (VPNs, a few company proxies and company ASNs excluded). There is a very long list of US-based ASNs that you can safely block completely.
3. resident proxies that come through DSL/Dialup/Cable networks. These are a bit of a bummer if you do have genuine users from the US as these are loads. It seems that everyone in the US and his uncle have installed bot/proxy software on their computer/device/TV-stick/Router, knowingly or unknowingly. So blocking those networks would solve a problem, however, it would also kill your user base there. So challenging is the way to go and - as many sellers of resident proxies claim that CF challenges would be no issue for them - possibly bot guard on top of that.

Thanks - where would I find ASN's for data centres in the US? Although actually I think most of them are residential proxies as well so I've edited my earlier post to say residential proxies.

 

[Alvin63]

Down to 200 guests tonight and 40 of those are actual known Robots.

 

[Alvin63]

I wouldn't assume it isn't working just from Claude's interpretation of the logs yet.

The definitive test is the direct-origin test after the .htaccess rule has been enabled.

Run this again:

curl.exe -I --resolve www.yourforum.com:443:YOUR_ORIGIN_IP https://www.yourforum.com/

If you now get:

HTTP/1.1 403 Forbidden

then it is working correctly, regardless of what Claude thinks it sees in the access log.

The fact that your site is still working normally is actually encouraging, because it means requests coming through Cloudflare are arriving with the correct header and are being accepted by .htaccess.

Copying the secret via Word/Notepad shouldn't normally matter, although hidden whitespace or a strange character could theoretically cause trouble. But if there were a mismatch between the Cloudflare secret and the .htaccess secret, your normal site should now be returning 403 as well.

So I would do the direct-origin curl test first before changing anything else.

If it returns 403, leave the configuration alone.

If it returns 200, then we can look at why the .htaccess rule isn't being enforced on your server.

Ok so redid the .htaccess in notepad and re-typed my header name and key rather than pasting them, Replaced .htaccess with the new one. Site still online.

Ran the curl command you gave and it seems to be working fine - got this. There was a bit more on the end but I left that off in case it was sensitive stuff I shouldn't post but wasn't sure.

HTTP/1.1 403 Forbidden
Connection: Keep-Alive
Keep-Alive: timeout=5, max=100
Date: Fri, 11 Sep 2026 21:52:46 GMT
Server: LiteSpeed
Vary: User-Agent

 

[Alvin63]

Ran the latest logs through Claude who says the China companies are all gone (yes I blocked China!). But also thinks there is an issue with images being blocked - what do you think? I can see images on the site fine in incognito mode. Has Claude misunderstood something here? Or are attachment files not getting header keys and being blocked from some people? @badabugs1

But I need to flag something urgent and important in the same breath: it looks like it's also blocking legitimate traffic — specifically, /attachments/ requests for everyone, including real browsers and honest, legitimate bots.

Look at what's actually in that 403 list: OpenAI's search bot, Bingbot, Googlebot, ExaSearchBot, and even Anthropic's own ClaudeBot — all getting blocked trying to view attachment images. And critically, an ordinary Chrome browser with a genuine referer from one of your own threads (chewing-bars-in-a-big-cage.1108) also got blocked trying to view an attachment.

This strongly suggests attachments are being served through a different mechanism that isn't correctly receiving your secret header, even for completely legitimate Cloudflare-routed traffic — meaning real members right now may not be able to view images/attachments on your forum at all, while regular pages work fine.

Good, this needs a bit more nuance — it's not blocking all attachment requests (969 got through fine with 200, only 554 got 403), so it's intermittent, not universal. But intermittent blocking of legitimate bots and real browsers is still a real problem worth understanding before you relax.

My best working theory: attachments might be served through a slightly different technical path than regular pages — possibly a different internal redirect, or even served via a separate DNS record that isn't proxied through Cloudflare the same way as your main domain (some sites deliberately set up a separate, unproxied path for media/attachments for performance reasons). If that's the case, some attachment requests might never pick up your Cloudflare header at all, even from completely genuine visitors, causing this exact intermittent pattern.

Given this is a real, live issue potentially affecting how members see images right now, I think the most useful next step is:

I found something genuinely revealing: bingbot appears in both lists — 61 times blocked, 22 times allowed. Same bot, same identity, sometimes getting through and sometimes not. That rules out anything to do with who is asking — this looks like something intermittently inconsistent in how the header gets applied, not a pattern based on visitor identity, referer, or bot status.

My best guess now: this could be related to Cloudflare's caching behaviour for images specifically — if an attachment is cached at Cloudflare's edge, it might sometimes serve straight from cache (bypassing the check, but also not touching your origin at all, so wouldn't show up like this) and other times pass through fresh in a way that doesn't reliably carry your custom header — possibly due to how image/attachment requests handle partial content (Range requests, common for images) or connection reuse under load. I don't have a fully confirmed mechanism, but it's clearly something structural about how attachments are requested, not about who's requesting them.

Given this is a genuinely important finding — real members and legitimate crawlers may be intermittently unable to see images right now — I think the responsible, immediate step is to add a safety exception for /attachments/ specifically, so this doesn't keep affecting genuine visitors while you investigate further:

apache

<IfModule mod_rewrite.c>

RewriteEngine On

RewriteCond %{REQUEST_URI} !^/attachments/

RewriteCond %{HTTP:Your-Header-Name} !^your-secret-key$

RewriteRule ^ - [F,L]

</IfModule>

This adds one extra condition: skip the block entirely if the URL starts with /attachments/ — meaning attachments would always load normally (as they did before this fix), while the main protection against the bypass swarm (which was never targeting attachments specifically anyway) stays fully intact.

 

[BrettC]

Just a tip for anyone else blocking ASN's in various countries - assuming this hasn't already been mentioned before.

Starlink's main global ASN is 14593 - it could show up in various countries (including Guyana and Myanmar). Also 397763 and 53348.

So Starlink Whitelist is those three.

Some that show up are for Mobile networks like Vodafone (India) 38266 and Orange (Tunisia) 37492 so I think it's important not to block those ASN's as maybe they could affect globally as well?

You can view all of Starlinks IP ranges here: https://geoip.starlinkisp.net/feed.csv - if there's a mismatched IP address to the given location, then there's an issue with a GeoIP feed somewhere. Otherwise, a general ASN ID should not result in incorrect blockages occurring.

https://www.peeringdb.com/net/18747 depicts their client-space AS ID. Starlink global IP range is primarily on AS14593.

There is a special AS ID of 45700, https://www.peeringdb.com/net/36005 for Starlink in Indonesia.

 

[BrettC]

Ran the latest logs through Claude who says the China companies are all gone (yes I blocked China!). But also thinks there is an issue with images being blocked - what do you think? I can see images on the site fine in incognito mode. Has Claude misunderstood something here? Or are attachment files not getting header keys and being blocked from some people? @badabugs1

But I need to flag something urgent and important in the same breath: it looks like it's also blocking legitimate traffic — specifically, /attachments/ requests for everyone, including real browsers and honest, legitimate bots.

Look at what's actually in that 403 list: OpenAI's search bot, Bingbot, Googlebot, ExaSearchBot, and even Anthropic's own ClaudeBot — all getting blocked trying to view attachment images. And critically, an ordinary Chrome browser with a genuine referer from one of your own threads (chewing-bars-in-a-big-cage.1108) also got blocked trying to view an attachment.

This strongly suggests attachments are being served through a different mechanism that isn't correctly receiving your secret header, even for completely legitimate Cloudflare-routed traffic — meaning real members right now may not be able to view images/attachments on your forum at all, while regular pages work fine.

Good, this needs a bit more nuance — it's not blocking all attachment requests (969 got through fine with 200, only 554 got 403), so it's intermittent, not universal. But intermittent blocking of legitimate bots and real browsers is still a real problem worth understanding before you relax.

My best working theory: attachments might be served through a slightly different technical path than regular pages — possibly a different internal redirect, or even served via a separate DNS record that isn't proxied through Cloudflare the same way as your main domain (some sites deliberately set up a separate, unproxied path for media/attachments for performance reasons). If that's the case, some attachment requests might never pick up your Cloudflare header at all, even from completely genuine visitors, causing this exact intermittent pattern.

Given this is a real, live issue potentially affecting how members see images right now, I think the most useful next step is:

I found something genuinely revealing: bingbot appears in both lists — 61 times blocked, 22 times allowed. Same bot, same identity, sometimes getting through and sometimes not. That rules out anything to do with who is asking — this looks like something intermittently inconsistent in how the header gets applied, not a pattern based on visitor identity, referer, or bot status.

My best guess now: this could be related to Cloudflare's caching behaviour for images specifically — if an attachment is cached at Cloudflare's edge, it might sometimes serve straight from cache (bypassing the check, but also not touching your origin at all, so wouldn't show up like this) and other times pass through fresh in a way that doesn't reliably carry your custom header — possibly due to how image/attachment requests handle partial content (Range requests, common for images) or connection reuse under load. I don't have a fully confirmed mechanism, but it's clearly something structural about how attachments are requested, not about who's requesting them.

Given this is a genuinely important finding — real members and legitimate crawlers may be intermittently unable to see images right now — I think the responsible, immediate step is to add a safety exception for /attachments/ specifically, so this doesn't keep affecting genuine visitors while you investigate further:

apache

<IfModule mod_rewrite.c>

RewriteEngine On

RewriteCond %{REQUEST_URI} !^/attachments/

RewriteCond %{HTTP:Your-Header-Name} !^your-secret-key$

RewriteRule ^ - [F,L]

</IfModule>

This adds one extra condition: skip the block entirely if the URL starts with /attachments/ — meaning attachments would always load normally (as they did before this fix), while the main protection against the bypass swarm (which was never targeting attachments specifically anyway) stays fully intact.

Just checked your forum, guest access throws the generic XenForo 403 error with "You must be logged-in to do that." I went ahead and made an account just now to see if such an issue persists. After validating my account, I am able to view file attachments on your forum without errors being thrown.

For example:


via https://www.thehamsterforum.com/attachments/img20260906203822-webp.14596/ which is from post https://www.thehamsterforum.com/threads/photo-comp-august-sept.3189/post-115961

 

[Alvin63]

Thanks yes I can see it in incognito as well. What was that about "you must be logged in to do that?"

 

[Alvin63]

You can view all of Starlinks IP ranges here: https://geoip.starlinkisp.net/feed.csv - if there's a mismatched IP address to the given location, then there's an issue with a GeoIP feed somewhere. Otherwise, a general ASN ID should not result in incorrect blockages occurring.

https://www.peeringdb.com/net/18747 depicts their client-space AS ID. Starlink global IP range is primarily on AS14593.

There is a special AS ID of 45700, https://www.peeringdb.com/net/36005 for Starlink in Indonesia.

Thank you. I'd better check my ASN block list then as I did block something in Indonesia.

 

[BrettC]

Thanks yes I can see it in incognito as well. What was that about "you must be logged in to do that?"

Guests are not permitted to view the non-thumbnail of attached images. I could see the attached image within posts, but poking the image to view the full image was not permitted. Which is generally an acceptable thing to do on a "get them to register" and a "bandwidth resource" point of view, IMHO.

 

[Alvin63]

Guests are not permitted to view the non-thumbnail of attached images. I could see the attached image within posts, but poking the image to view the full image was not permitted. Which is generally an acceptable thing to do on a "get them to register" and a "bandwidth resource" point of view, IMHO.

Thanks. So in that case maybe it's normal for Googlebot and other known bots not to be able to see images? As they are guests too.

 

[BrettC]

Thanks. So in that case maybe it's normal for Googlebot and other known bots not to be able to see images? As they are guests too.

To be honest, and this is just my own opinion on the matter, indexer bots really don't need to "see the image", so long as the images have been surrounded by text in a post to give context, or the image and its associated link has something describing the image.

 

[Alvin63]

I reverted the .htaccess and downloaded the logs again about 10 minutes later and Claude has decide it's exactly the same re the images and normal Xenforo behaviour. So that's good - I can put it back again now. It doesn't seem like I have an origin leak anyway. The slightly frustrating thing is the logs don't show if the Cloudflare header is there or not so can't be sure.

 

[Alvin63]

No evidence of origin leak but Claude seemed quite upset that the logs showed Anthropic got rate limited a few times!

 

[BrettC]

No evidence of origin leak but Claude seemed quite upset that the logs showed Anthropic got rate limited a few times!

Feel free to DM me your servers real IP address behind the Cloudflare route. I can poke about and do some checks on my end.

From visiting your main sites landing page:

alt-svc
h3=":443"; ma=86400

cache-control
private, no-cache, max-age=0

cf-cache-status
DYNAMIC

cf-ray
a39a74a85dee4e03-MCI

content-encoding
zstd

content-type
text/html; charset=utf-8

date
Fri, 11 Sep 2026 23:29:38 GMT

expires
Thu, 19 Nov 1981 08:52:00 GMT

last-modified
Fri, 11 Sep 2026 23:29:38 GMT

link
</js/xf/preamble.min.js?_v=bca7a5c7>;as=script;rel=preload,</css.php?css=public%3Anormalize.css%2Cpublic%3Afa.css%2Cpublic%3Acore.less%2Cpublic%3Aapp.less&s=7&l=1&d=1788151970&k=fd9e20032971303b8e578efcfbaa6b5336d21a94>;as=style;rel=preload,</js/sv/lib/link-post.min.js?_v=bca7a5c7>;as=script;rel=preload;fetchpriority=low,</js/vendor/vendor-compiled.js?_v=bca7a5c7>;as=script;rel=preload;fetchpriority=low,</js/xf/core-compiled.js?_v=bca7a5c7>;as=script;rel=preload;fetchpriority=low,</css.php?css=public%3Anotices.less%2Cpublic%3Arating_stars.less%2Cpublic%3Astructured_list.less%2Cpublic%3Axa_ams.less%2Cpublic%3Axa_ams_tile_view_layout.less%2Cpublic%3Axb.less%2Cpublic%3Aextra.less&s=7&l=1&d=1788151970&k=c16eedd134103f725983cb8c6b6670789b0d1fad>;as=style;rel=preload;fetchpriority=low

nel
{"report_to":"cf-nel","success_fraction":0.0,"max_age":604800}

report-to
{"group":"cf-nel","max_age":604800,"endpoints":[{"url":"https://a.nel.cloudflare.com/report/v4?s=6RAGHipMc4H%2FyCx3WKwUA4i5luGlovzfrD8rKEiBBq8YT5105evTDmSp0RSPD4wYHedMqts%2FRjuIGfiQbYOdKdgU5wGAgUjGc3%2FJzcZ6bnZiCu%2BiCNjBsj1g897q2TKjf7zinB54G7ndEb83jDOhQwReHF7AaA%3D%3D"}]}

server
cloudflare

server-timing
cfCacheStatus;desc="DYNAMIC"

server-timing
cfEdge;dur=3,cfOrigin;dur=338

vary
Accept-Encoding,User-Agent

x-content-type-options
nosniff

x-frame-options
SAMEORIGIN

x-turbo-charged-by
LiteSpeed

Cloudflare is indeed functional. I don't see any leakage from a glance.