The Downside of going serverless
But after a while reality kicked in. I was playing around with some IPv6 systems, when it hit me. With the previous design, the site would show only the primary IP-Address of the client. If the client supports both IPv6 and IPv4, it would still only show one IP-Address.
I tried a bit around. Eventhough Cloudflare allows DNS Host A (IPv4) and AAAA (IPv6) entries, it wouldn’t work as I wanted. Cloudflare needs to proxy the DNS entries, to make Cloudflarer Workers work. And even if you only add one IP Version, it would still proxy for both Internet Protocol versions. So the reality of serverless is: You only have very limited control over the server that hosts your application. For some scenarios that might be okay, for others not.
I wouldn’t really call this a fix, just a hacky workaround. I created a subdomain
alt.simpleip.de that points to a Shared Webhost Account at Netcup. In my Netcup Customer Control Panel, I added two Subdomains (or rather Sub-Subdomains):
I then added “Let’s Encrypt” TLS certificates and put a small PHP-Script on the server. The script outputs the IP-Address of the client using
The trick is, that
v4.alt.simpleip.de only has a Host A Record - so it only works for IPv4 clients. And
v6.alt.simpleip.de only has a Host AAAA Record - so it only works for IPv6 clients. Initially I wanted to use
ipv6.alt.simpleip.de, but apparently a bug in the Netcup Plesk Control Panel prevented that 🤔. Weird.
- Cloudflare Workers injects the Client-IP-Address into the HTML and delivers the site (No Client-JS needed).
- When the HTML Body loads and Client-JS is enabled:
So it’s still kinda serverless, since I don’t administer the Webserver at Netcup 😇. It’s a Shared Webhost package. When going serverless, there are several obstacles, but there’s mostlikely a Workaround. For my use case, I still prefer these workarounds instead of administering a full server.