All right, there is no entry whatsoever, so it shouldn’t have been whitеlisted by a previous rule either.
These requests will probably connect directly and the best course of action would be to make sure only Cloudflare can connect.
I am afraid that’s not a very reliable approach.
Follow Restoring original visitor IPs · Cloudflare Support docs instead and make sure your firewall does not accept connections from addresses other than IP Ranges
What do you mean it’s not a good approach? I’m basically using PHP as my firewall and instead of have Block, set it to Log.
I will investigate more about direct connections, but I don’t think that is how this is happening.
I have IPV6 Disabled.
PHP is not a firewall, your approach is rather a hack than a proper implementation I am afraid. We also don’t know if that list is even accurate, apart from you mixing integers with strings. Again, I highly discourage you from using this approach.
Can you post a screenshot of https://dash.cloudflare.com/?to=/:account/infinitesweeps.com/security/events?action=skip?
I’m not sure what you mean.
The list is accurate, or I’d start seeing Cloudflare ips in my logs 
It’s not integers, it’s Cloudflare’s IP Address’s converted to ip2long. The list is found here: IP Ranges
I will turn on my firewall tomorrow morning and make sure, there is just no need to have the firewall locked down and I use the server for other things that are not on cloudflare.
What’s the screenshot of the skip for? Do you want that with the IP? or ?
No, just post the screenshot as mentioned.
So you do have skip rules. If those are getting applied to those requests, the challenge will be skipped as well. I’d recommend to go through your skip rules and make sure you are not skipping requests you do not want to skip.
I did…
Every single one of those is user agent
- ias-va/3.3 (former https://www.admantx.com + Integral Ad Science | Digital ad verification solutions for all screens and devices)
162
- ias-or/3.3 (former https://www.admantx.com
2 of them. I have other skip rules but they are set to not log. It’s only Google Bots and stuff… No ISP or anything. Only Bing Bots Etc.
What you’re saying, no matter if they got allowlisted anything should Log. It’s not logging anything, yet they are requesting the page and it’s not showing anything.
I’ll post here soon after I firewall it, but i’m not sure how that’s different than what i’m doing in PHP.
Something weird happening… It’s definitely not bypassing Cloudflare.
Fair enough, then you are probably not skipping these particular requests.
As mentioned, make sure you follow the previously referenced guides to secure the server. Once they can’t connect directly, the challenge should always work.
LOL! Ok, the firewall is now on (.htaccess rules. Will post here when the next request comes through 
It just happened: IP: http://98.197.206.x
User agent: Mozilla/5.0 (iPhone; CPU iPhone OS 11_0 like Mac OS X) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.4924.1805 Mobile Safari/537.36
Events: NONE
Requests still seem to be accepted by your web server however.
What do you mean? I did a htaccess server wide, but it still happened (see above).
.htaccess is just a web server configuration file and not a firewall, you need to configure this with your firewall instead.
What’s the difference? I had htaccess setup to not allow any IP through to the website.
The IP loaded, but that’s because it’s through CPANEL.
Basically, if an IP is not Cloudflare, it cannot get through to the server or make a request to the page… but it’s still happening.
I’ve removed the htaccess rule, as I have other things I use that access the IP directly.
I will try to investigate more today…
It also makes me notice another issue:
I also see more and more Cloudflare IP Requests. This is normal to be through the Newsletter, but there are Cloudflare IP Requests navigating the page now.
It’s almost like they are using Cloudflare Workers to visit my page, something like this: GitHub - aD4wn/Workers-Proxy: A lightweight Javascript Reverse Proxy built with Cloudflare Workers.
Workers-Proxy is a lightweight Javascript Reverse Proxy based on Cloudflare Workers.
Users could deploy the reverse proxy on Cloudflare’s global network without setting up virtual private servers and configuring Nginx or Apache.
Features
- Build mirror websites
- Improve loading speed with Cloudflare’s global network
- Increase security (Hide IP addresses of websites)
- Block specific areas or IP addresses
- Redirect mobile users to different web pages
I have like a user that logs in via Cloudflare and lots of weird Cloudflare requests, when they used to ONLY be newsletter requests that have query strings
How can I detect Cloudflare Worker requests that are not mine ? If somebody is mirroring my page (which it looks like to me), they can effectively do anything with that data to bypass my detection.
The difference is that your server is still accessible and that’s exactly what we discussed.
The Workers question is a bit unrelated as that would still go through the firewall.
It’s not, it’s accessable at a different level (cpanel) not the domain. I’ll try to do a firewall as well later but pretty sure it’s not going to do anything.
I diabled the htaccess rules right now. I only want to do a firewall or htaccess if i’m “under attack” or if they are some how directly accessing and it’s some how breaking the
If(remote IP is in cloudflare range ( do stuff ) ) else LOG
Htaccess rules
firewall rules
PHP rules
That all look for an IP that is not on the CLouflare Range, all do the same thing. The firewall is just the first level which saves more resources.
Sorry but we are going in circles here. The server still is accessible and that’s what you should fix and what we have discussed hours ago. As long as your server is not properly configured, you you may always have direct requests, hence why you should follow what we discussed.
Dude, your repeating the same thing without listening.
THEY ARE NOT DIRECT REQUESTS. I HAVE LOGS blah
- I would appreciate if you did not call me dude
- You have not yet provided any proof that these are not direct requests
- We have proven however that the firewall works as intended
- If you do not follow advice but simply keep rehashing that your system is secure, then it will be certainly a bit difficult. Neither your “firewall” approach nor your IP rewrite approach seem to confirm that however