Imunify360 is returning a JavaScript captcha challenge (~854 bytes referencing aes.js / slowAES) to all server-to-server requests made by Vercel’s reverse proxy to my WordPress site at nutricionistaemnatal.com.br.
Other Information
Setup: I use Vercel as a reverse proxy so that matheusmedeirosnutri.com.br/blog serves content from my WordPress site at nutricionistaemnatal.com.br (hosted on InfinityFree, account if0_42428183). This is a standard SEO technique to keep everything under one domain.
Problem: Imunify360 is intercepting all server-to-server HTTP requests from Vercel with a JavaScript captcha challenge. The response is ~854 bytes containing a script that references aes.js and slowAES. Since Vercel’s servers cannot execute JavaScript, the proxy never receives the actual WordPress content.
I confirmed this by checking the response headers: there is no CF-Ray header, content-length is exactly 854, and x-vercel-cache shows MISS. Every path I tested (/wp-json/, /feed/, /) returns the same challenge page.
Request: Could you please whitelist Vercel’s egress IP ranges in Imunify360 for the domain nutricionistaemnatal.com.br? The proxy requests originate from Vercel’s GRU1 region (São Paulo, Brazil). Alternatively, disabling the Imunify360 JavaScript challenge for this domain while keeping other protections active would also solve the issue.
I don’t know why you straight up assumed that we have Imunify360 but whatever, there is a security system that’s not called Imunify360, and is mandatory on free hosting.
My guess is AI assumptions. Premium hosting does have Immunity360, free hosting doesn’t. But I was under the impression that Immunify was more about malware protection than web filtering, so this doesn’t add up at all.
As for the specific question asked: no, we won’t do that.
Vercel is not a proxy service, it’s a hosting service, and we’re not going to open up our entire platform to every single application hosted on Vercel, as that creates a massive security hole in our system.
Our system currently functions on all sites and all URLs, with no possibility to make an exception. We don’t want to give people the option to disable these security measures themselves as it exposes not just your website, but the entire server to undesired traffic, and manually vetting requests is way too labour intensive for a free hosting service.
I’m not sure sure about your assessment that having the blog on a subdirectory instead of a subdomain is so much better for SEO, I’m pretty sure that search engines are aware that the distinction is mostly cosmetic, and will correlate these things as being the same site. And hosting a single hostname at multiple hosting providers is inherently messy.
If I were you, I would consider the following options:
Move the blog to a subdomain, e.g. blog.matheusmedeirosnutri.com.br, and host that subdomain directly with us without a proxy.
Host both components on a single hosting provider. You could host the landing page with us or the blog at Vercel.
If you absolutely insist on the proxy route, maybe look into doing it with Cloudflare. Running websites on our hosting behind Cloudflare is very common and works fine, and maybe it’s possible to use rules in Cloudflare to split the traffic.
ImunifyAV(+) is anti-virus only. Imunify360 is a more complete security solution which does include web traffic protection (I’ve seen it in action quite a few times already).