[pmjordan]

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.

[billpg]

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.)

[pmjordan]

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.

[billpg]

There are ISPs that will route all (or some) port 80 traffic into a bank of caching proxies but route traffic for all other ports normally.

(GRC.COM's 'Shields Up' service makes a point of using HTTPS to make sure it's testing your external IP rather than a random proxy server.)

I suppose it depends on what you actually want to use the returned IP for. As you say, the concept is hazy.