The response of a fetch() request in worker is different from same request in any other environment
I have a domain xolotto.com and subdomain blog.xolotto.com managed by Cloudflare.
When I make a request from any browser https://blog.xolotto.com I have the response STATUS 200 OK and the content of the test page, which is expected.
However when I make a fetch request to the same resource from the worker, the result of the fetch is STATUS 403 UNAUTHORIZED:
export default {
async fetch(request, env, ctx) {
let blogResponse = await fetch("https://blog.xolotto.com") // returns 403 UNAUTHORIZED
return blogResponse;
},
};
The worker with the code above is deployed here: https://twilight-voice-3b23.xolotto-account.workers.dev/
The issue first showed up about 2 weeks ago. Before that everything was working fine for a few years, no code changes in the worker or test page code. What could cause the issue and how I can fix it? From the worker’s dev tools I cannot know the IP address of the origin server of blog.xolotto.com. Is it possible that the worker resolves DNS lookup to a different IP?
The origin server for blog.xolotto.com is Hostinger and they recently changed their IP to 45.80.182.143 and asked to update the DNS A record, which I did in Cloudflare.
12 Replies
When i run
dig a blog.xolotto.com @1.1.1.1 i get an A record with 104.22.52.117 (and 2 other results) which looks like you are proxying blog.xolotto behind Cloudflare. Is there anything in your Analytics / Security logs area in Cloudflare? You could temporarily try modifying the 'security level' or turn off proxying.Thank you for your answer! Yes, blog.xolotto.com was proxied with Cloudflare. Now I've turned proxying off, the IP address is updated to origin server IP, but it doesn't help unfortunately. The .htaccess file on the hosting side has "Allow from All" directive.
The 403 page that is returned isn't a Cloudflare error page. I would check your server again, as it seems something on that end is returning the error
Do you have logs from the server?
I see what you mean, I created a basic test and when I run it locally or with --remote I get "PHP test 45.80.182.143". As soon as I deploy it onto Cloudflare. I get the 403 Forbidden page. As per Hard@Work | R2's comment, the Hostinger server is selectively blocking Cloudflare addresses. Is your Hostinger account a VPS, if so can you try this : https://support.hostinger.com/en/articles/4805502-how-to-set-up-a-firewall-at-vps#h_2a7483333c . Otherwise, I would reach out to their support.
Thank you for your help! Unfortunately there is no logs on the server that is from Cloudflare's worker. Looks like requests were denied either before reaching our app or DNS lookup returns incorrect IP address, so it doesn't reach server at all. I suspect that the IP address can be resolved incorrectly because issue started shortly after Hostinger changed their IP and asked to update DNS A record.
I tried to contact Hostinger's support, they asked to add some headers to request (User-agent, referrer & accept), but it didn't help. Since the issue started shortly after Hostinger changed their IP address and the A DNS record was updated in Cloudflare, I can assume that the DNS lookup for worker can be resolved incorrectly. Is it possible to check somehow which IP address worker send requests to?
DNS over Discord: A records
blog.xolotto.com A @1.1.1.1 +noall +answer +short
diggy diggy hole
DNS over Discord: AAAA records
blog.xolotto.com AAAA @1.1.1.1 +noall +answer +short
No records founddiggy diggy hole
The above IP address is the one Workers would use
I don't know of any programmatic way to get the IP actually used by the fetch() ..
I get the following headers on the 403 response
panel: hpanel
platform: hostinger so it does seem to be a hostinger server responding.
Are you able to see the successful/failed requests in Hostinger's access logs?
https://support.hostinger.com/en/articles/5650167-how-to-use-the-analytics-section-on-hpanel#h_0060feb18eThank you so much for sharing that. I didn't even know that logs are exist! And yes there are logs of failed requests from Cloudflare!
@rdutton @Hard@Work | R2 Thank you so much for your help! Looks like issue is on the Hostinger side. I will post updates once resolved.