I have something very similar, and all my projects depend on that. I also made a copy of httpbin which I host on a server. Useful for unit testing. And a gateway for hookback urls that I use for relaying/logging oauth and similar things to internal vpns. All very useful gadgets that have been running for over half a decade on arch.

If it's on the public internet, you're not forcing anyone to provide you a service. Standing up reliable infra isn't easy nor free, no matter how trivial deploying it may be.

Probably more efficient to use https://lib.rs/hyper - and actually maintainable.

I can't say a thing about efficiency, but for maintainability, I have to disagree. This seems to be a rust library, and for maintaining that, you'd need to write a program, compile it every time some updates come by, rerun the recompiled program, ...

With the parent comment example, all you need is nginx, available as a package on all distros, and a single static config file. With an auto-updating package manager and a service manager, one never needs to write anything else apart from that static config file.

Or did you mean something else with "actually maintainable"?

I would trust the rust compile/rerun process a lot more than an auto-updating linux distribution, personally. Sooner or later that auto-updating package manager will break your config file, itself, or both.

The majority of nginx distributions will not get any major bumps during the lifetime of the distros they're in. Whether that's because the distro itself has policies against that (Debian, Ubuntu) or because the distro version expires before nginx' stable release does (most of the ones with a higher update frequency, ie. Fedora) so by the time the version expires, they can just go to the next stable version on the release after. This is pretty much only a risk if your distro is completely rolling release and even those in my experience at least offer an "lts" package of some sort.

So that's not a problem. Besides the majority of nginx setups don't rely on too fancy things; most of the stuff that gets changed in updates that affect config files are the fancier nginx modules.

> The majority of nginx distributions will not get any major bumps during the lifetime of the distros they're in. Whether that's because the distro itself has policies against that (Debian, Ubuntu) or because the distro version expires before nginx' stable release does (most of the ones with a higher update frequency, ie. Fedora) so by the time the version expires, they can just go to the next stable version on the release after.

If you're following that approach then having auto updates enabled is kind of irrelevant/meaningless; at some point you're going to be running a very old (and unsupported) version of your distro with all that that implies.

That is true, yeah. But the library in question will also eventually break the existing API / stop supporting compatible releases with security patches. I assume this nginx config will still work for many releases in the future.

> But the library in question will also eventually break the existing API / stop supporting compatible releases with security patches.

Maybe. I have more faith in a Rust library to maintain API backward compatibility than a Linux distro, is what I'm saying.

This will return the wrong results when used behind a load balancer

Anything would return proxy/LB address. So do not use it behind LB/proxy/NAT.

Not if you use the PROXY protocol

Ok, I'll bite... What kind of machine do you host this on that can handle 400,000 of these requests (with TLS mind you) per second? That was the load he mentions it handling in 2021, he stopped mentioning requests per day metrics after that.

400,000 req/s is actually not crazy. Back in the single-core era I was doing 1/10th of that on a production server for similar workloads a compiled VB / COM+ app. I would wager Nginx can handle that pretty easily on a modern dual or quad-core system.

The thing is, at that rate, you'll likely run out of ports without more advanced / exotic TCP configurations.

Tcp connections are a 4-tuple {PeerAIP, PeerBIP, PeerAPort, PeerBPort}, if you hold your IP and port fixed, because you only listen on port 443, you can do 64k connections to each other peer's IP... if the other peer can manage to use them all.

Chances are you'll never run into that limit for this service, because even if there's a ton of users behind the same IP due to NAT, they don't need to hold long sessions, and you can disable http keep-alive and close connections right away. Chances are you'll have some ip diversity in 400k requests/second though.

I think you are misunderstanding... the point of self hosting is that you only need to handle your own load. It only needs to scale to what, 1 request per day?

Wasn't the original target of nginx back in the nineties to hit 100k requests per second with less overhead than (at the time, standard) apache2?

With that in mind + the general advancing of hw since then, it wouldn't be too suprising if nginx could handle that load easily. It'd just get more difficult if you wanted to put anything else (ie. metrics) on that endpoint since afaict nginx doesn't have anything to monitor those things if you don't have the Enterprise version of their tools.

In any case you might be misreading the setup for the parent here - the recommendation is just that if you're doing this in the context of a webapp, that this sort of behavior is trivially easy to bounce back in JSON using nginx.

No, the point is, you host it for your own needs, so you are not using their service. Your implementation is for YOUR needs. You can make it public or not and advertise it or not at your discretion. What we do is make it public, but don't advertise it at all. Our software just uses it when needed.

If your use case calls for 400k/reqs a second on what your IP is and you haven't yet figured out how to build out your infrastructure(or pay someone to do it for you), you have bigger problems than figuring our what your public IP is.

Alternatively, with Caddy (with automated TLS, single static binary):

    example.com {
        handle /ip {
            header Content-Type application/json
            respond `{"host":"{host}","ip":"{remote_host}","port":"{remote_port}"}`
        }
    }

Though the usefulness of the host (client specified it), remote port (it's random), and server ip/port (it's static and not useful for the client) are questionable.

Useful for UA sanity checking I guess

Alternatively, search the web for everyone implementing "/ip" and random load balance between all of them and let them handle the load for you.

My favorite: https://cloudflare.com/cdn-cgi/trace

/cdn-cgi/trace isn't available on just cloudflare.com, it's on every site they proxy too (there might be a setting somewhere to disable it yet it's on by default). I've yet to figure out what happens if your site also serves something there, yet it was surprising to see on a barebones site I had routed through them.

I learned this from: https://news.ycombinator.com/item?id=36383258

TIL. Looks like they have it documented (since Apr 2022, based on the github history), it cannot be modified or customized, and that it sometimes causes problems with SEO crawlers!

https://developers.cloudflare.com/fundamentals/get-started/r...

   sni=plaintext

There was a great trial CF ran for a long period with a previous version of encrypted SNI (now ECH). One could get encrypted SNI with any site using CF via modified OpenSSL. But they stopped this experiment. Meanwhile ECH was still not ready.

If anyone is getting something other than "sni=plaintext" for a CF domain besides crypto.cloudflare.com, then please let us know how.

Isn't ECH still off by default in most browsers? The latest info I could find has it implemented but opt-in behind experimental flag in both Firefox and Chrome, and not supported at all in Safari.

And only enabled by CF in certain regions. Not sure.

That's neat, but that's the opposite of what I'm suggesting. I'm saying if you are hosting web content anyway, then just host a /ip endpoint that returns the IP address. That way you aren't forcing other people to carry your load.

Another one

https://whatismyip.akamai.com/advanced?debug

DNS-based

   drill whoami.akamai.net 

The second one might be useful to verify one is not using local, ISP-provided DNS, or to see whether a DoH provider effectively geolocates its users, e.g., Cloudflare.

Bad cert. The common name does not match the subdomain.

Certificate says CN is a248.e.akamai.net

CNAME for whatismyip.akamai.com is a1524.g.akamai.net

Probably no certitifcate that lists whatismyip.akamai.com

Another DNS based one:

  dig ip @dns.toys +short

Another one

Send a request to stackexchange.com or any of its subdomains without a user-agent header.

Now I just need the apache config for this...anyone?

great callout! A more advanced self hosted option can be https://github.com/mpolden/echoip