Scan initiation failed

Cloudways Hosting:

We have checked the logs and could not see any requests being made by the IPs that you have shared above.

Further, we do not block any requests from any IP on ports 80 and 443 at the Server Level. It can be blocked by any security plugin being used on the application or via .htaccess file. There is nothing in your .htaccess file that would cause this issue.

Hi @joyryde

Thank you for checking with them.

This means that our requests never even reached the server which would take us back to CloudFlare.

I just tested it from my own end trying to emulate request

curl --header "X-Forwarded-For: 165.227.127.103" -I -A "WPMU DEV Broken Link Checker Spider" "https://nomadicsupply.com"

and also got 403 Forbidden response from CF directly:

HTTP/1.1 403 Forbidden
Date: Wed, 19 Jul 2023 11:29:49 GMT
Content-Type: text/html
Connection: keep-alive
CF-Ray: 7e92a0fc5e533512-WAW
CF-Cache-Status: DYNAMIC
Vary: Accept-Encoding
Set-Cookie: __cf_bm=EKqGnPkR_7q1WxRLAIh1ugZuCiokSx_Xmh3UCT5cFgQ-1689766189-0-AcOB06y+0l2CvJsYYmBvifHmpwK1/0U1HXoiJ+7YAZBt7hyuRj0LaZHcaR7KXa1VXf+dOFnaWqyWr21cT948jzk=; path=/; expires=Wed, 19-Jul-23 11:59:49 GMT; domain=.nomadicsupply.com; HttpOnly; Secure; SameSite=None
Server: cloudflare
alt-svc: h3=":443"; ma=86400

That being said, CF responses include “Ray ID” in header so I run another request from a different network (with same results) and I got these two Ray IDs

7e92a0fc5e533512-WAW

7e92a7cba94b17e9-EWR

Could you follow this guide

https://developers.cloudflare.com/fundamentals/get-started/reference/cloudflare-ray-id/#security-events

and let us know what the log shows for these Ray IDs?

Kind regards,
Adam

Cloudflare Activity Log:

No firewall events found

Hi @joyryde

Thanks for response!

That’s really strange, I must say.

HTTP responses to HTTP requests from our end are very clear and there simply must be something that’s in some way blocking those requestes.

If it’s not CloudFlare and there are no traces of requests from us in server access logs, there must be some additional aspect that we are all missing here.

So I did some more checks using external services (meaning IPs wouldn’t be related to us at all and request headers/user-agent strings would be different) and:

1. https://reqbin.com/curl

I used

curl -I https://yoursitedomainhere

command there and issued it first using “US” and then using “DE” location – in both cases it got the same “403 Forbidden” response.

2. on the other hand, same command issued locally from my own PC console (so from my own location/IP) returns expected “200 OK” response; tools such as GTMetrix seem to work fine too

So it looks to me like there’s either something very specific as, apparently, it’s not only us being rejected this way – but also not every service.

I’m wondering then

– if there is any additional firewall/security on your hosting that may actually be set in a way that rejected requests are just not logged in access log (but in that case there should be another log, like WAF log or similar firewall log). Could you please double-check that with your host support (btw, would you mind telling us who are you hosting with? – this may be helpful)

– are you using any additional security tool “offsite” such as e.g. Sucuri?

– or maybe there is some additional proxy or load balancer in front of the actual site but “behind” CloudFlare?

Kind regards,
Adam

Hi,

You already had us check with the host, please see above where they replied to you 2 weeks ago:

Cloudways Hosting:

We have checked the logs and could not see any requests being made by the IPs that you have shared above.

Further, we do not block any requests from any IP on ports 80 and 443 at the Server Level. It can be blocked by any security plugin being used on the application or via .htaccess file. There is nothing in your .htaccess file that would cause this issue.

Hi @joyryde,

Thanks for the update. Let us try to rule out Hosting firewall by pausing the Cloudflare to see if the issue is related with it.

You can temporarily pause Cloudflare by:
– Going to the Overview tab in the Cloudflare dashboard.
– At the bottom right of this page there is a link under Advanced Actions .
– Click Pause Cloudflare on Site

Please inform us about the results accordingly.

Kind regards,
Zafer

Paused Cloudflare. Same result. Cloudways also uses Cloudflare on all websites internally, so we aren’t sure if that’s an issue. It’s part of their hosting, separate from Cloudflare accounts like mine.

Scan initiation failed

The site may be offline or inaccessible due to a security firewall or other reasons. Please add BLC user agent and IP to your allow list as as outlined in our troubleshooting guide and retry the scan. Contact support if the issue persists.

Hi @joyryde,

Could you please consider creating a staging version of your website on a separate server, preferably outside of the Cloudways hosting environment, and see if you are still able to replicate the issue? This can help further isolate and troubleshoot the problem.

Kind Regards,
Nebu John

Hi,

We have a staging site, on Cloudways, as that is our hosting company.

Hi @joyryde

We have a staging site, on Cloudways, as that is our hosting company.

Thank you for letting us know but

– what about the issue on staging site – is it also happening there?
– if yes – would you be able to try to create such staging site somewhere outside Cloudways and see if issue is happening there too? My colleague suggested it for a reason and the reason is to be able to confirm or rule out if the issue is in anyway related to hosting.

Kind regards,
Adam

I’m giving up, this software doesn’t work.

Hi @joyryde,

I just checked by re-running a new scan via the Hub and it does seem that the scan did start this time and it no longer showed the “Scan initiation failed” message.

However, I’m afraid the results in the BLC scan are pointing to a 403 error when it tries to scan the internal URLs.

I’m afraid, the issue is still regarding the existing Firewalls you have enabled on the Cloudflare side.

Seems like the actions you have performed have only whitelisted the homepage URL, the internal URLs aren’t able to scan and throwing the 403 error.

You can try running the cURL command as mentioned in the previous reply here:
https://www.ads-software.com/support/topic/scan-initiation-failed/page/2/#post-16906223

And you’ll still notice the cURL command to these internal URLs listed in the BLC scan result is still throwing the same 403 error.

HTTP/2 403 
date: Fri, 11 Aug 2023 11:16:55 GMT
content-type: text/html
cf-cache-status: MISS
vary: Accept-Encoding
server: cloudflare
alt-svc: h3=":443"; ma=86400

Please note that the issue isn’t related to BLC but with the existing Firewall configuration. Unfortunately, what we could comment about which exact setting causing such behaviour is limited.

The only way to rule out would be to unblock the configuration added for the Firewall one by one and check on what exact point a new scan works.

Please do let us know if you want us to check anything specific regarding this.

Kind Regards,

Nithin

We replied to that post already, we followed the instructions for Cloudflare and it’s not something that exists in our account, their website says:

Cloudflare Activity Log:

No firewall events found

Hi @joyryde

I hope you are doing well.

We understand that the event logs are not being registered in Cloudflare, but we only report the header status that we get on cURL tests, which note, is not directly related to any request plugin side,

I did check it once again and seems we are a step forward, the regular cURL is now returning 200 status:

 ~ % curl --header "X-Forwarded-For: 165.227.127.103" -I -A "WPMU DEV Broken Link Checker Spider" "https://nomadicsupply.com/consumer-priority-service-extended-warranty-plans/"
HTTP/2 200 

The service is able to start so the server communication is being done, however, inner links are returning 403 when the server runs but not when we do a single request.

Do you have any rate limit in your hosting?

The crawler is going to request 5 links at the same time, and depending on configuration it can block some API requests.

I also understand you already requested your hosting support to check it, but can you verify the Access log https://www.cloudways.com/blog/view-access-error-logs/ and check the accesses from those IPs:

HUB API
18.204.159.253
54.227.51.40

Broken Link Checker IPs
165.227.127.103
64.176.196.23
144.202.86.106

Especially for the Broken Link Checker IPs and see which status code the hosting is returning for them.

This can point us in the correct direction, for example, if you don’t see any access for the above IPs the block is happening even before the server can be accessed, but if the access log show those logs as 403 then we remove Cloudflare from troubleshoot list and need to look into Wordfencen and Jetpack for example trying to disable them temporarily.

Best Regards
Patrick Freitas

Cloudways Hosting responded:

These IPs are not making any connection to the server at any time. Here is a screenshot for you:

If it were an issue from the server then there would be a log.