HTTPS can be proxied, too, transparent or not, and you'll end up with the proxy's IP. (as the HTTP headers are encrypted along with everything else, the proxy can't even include an 'X-Forwarded-For:' header) Still useful for maintaining the full 'lock' icon when embedding in other websites, though including jsonp in an https site somewhat defeats the purpose. You'd need CORS on the server for it to be useful.
An HTTPS proxy can only work when the client explicitly configures it. A proxy that can't cache or modify traffic is more like a NAT router than a proxy.
(I imagine getting the IP of the other side of any NAT router is point of this service.)
You can transparently proxy arbitrary network traffic. See https://github.com/apenwarr/sshuttle for an example. FWIW, I'm only pointing out that HTTPS wins you exactly nothing compared to HTTP for this particular purpose. The concept of the "correct" IP address in the context of NAT and proxies is hazy at best anyway.
Which might be exactly what you want if you are troubleshooting HTTP issues with customers "Go to page X and tell me what it says" rather than "what is your IP" is much more reliable.
If there's a proxy, there's a proxy - but I can't troubleshoot the customer's connectivity issue without that.