Also, there's no reason to believe that you're curling the same redirect as you get from clicking the link.
There's this thing compromised webservers do where, if you type in www.example.com into your browser, and go straight there, you get the normal web page. If you click a link from Google, and have a google.com referrer in your request, you get a little bit of JavaScript included that that redirects you to another site to buy herbal remedies or fake watches or whatever.
If you are the business owner and go directly to your home page to see what's what, you think everything is fine; if you are a tech trying to debug it and you curl the webpage, everything looks fine [unless you curl with a referrer set]. You probably think Google has the wrong URL or something.
Likewise -- I don't know what a click-through from an email client looks like, but it wouldn't surprise me if there's an identifiable header or referrer or something. If that's the case, you could write your malicious URL shortener to redirect you to www.example.com/ if you curl it bare, or www.exam.ple.co/m/ if you have the redirect header. Curling the URL in question doesn't necessarily prove it's safe to click on.
Not that depressing. Audit your current web server configurations. You can dump the in-memory representation generally. Diff it with the on disk representation, and bam. Instant canary. If you're worried about a tainted on disk version, do the integrity check against a version invisible to the outside net.
Also, redeploy configs and reload on the regular, and you essentially force an actor to get an active foothold on your system to re-exploit and persist the compromise.
It's not impossible to defend yourself against these types of things if you're vigilant. You can also script your deployment to the point where you can nuke your site from orbit with minimal impact, and reestablish it. It's all about your threat model.
But yes. Things like nginx, apache & co are remarkably comprehensive in the things you can configure them to do. I find that my most dreaded part of standing up a new service is inevitably writing the load balancer/host web server configs.
There's this thing compromised webservers do where, if you type in www.example.com into your browser, and go straight there, you get the normal web page. If you click a link from Google, and have a google.com referrer in your request, you get a little bit of JavaScript included that that redirects you to another site to buy herbal remedies or fake watches or whatever.
If you are the business owner and go directly to your home page to see what's what, you think everything is fine; if you are a tech trying to debug it and you curl the webpage, everything looks fine [unless you curl with a referrer set]. You probably think Google has the wrong URL or something.
Likewise -- I don't know what a click-through from an email client looks like, but it wouldn't surprise me if there's an identifiable header or referrer or something. If that's the case, you could write your malicious URL shortener to redirect you to www.example.com/ if you curl it bare, or www.exam.ple.co/m/ if you have the redirect header. Curling the URL in question doesn't necessarily prove it's safe to click on.