Hey there @fedex1,
If you share a proxy or custom application you can inspect, manipulate, and enforce rules based upon the HTTP headers, documents, etc. that are submitted to your share.
You cannot block clients at the public proxy layer by IP address, but you can "see" the client IP in the X-Forwarded-For header that is forwarded to your application, e.g., a reverse proxy. Alternatively, you can use public share backend mode "caddy" to potentially write a Caddyfile or raw Caddy configuration object that expresses certain rules, like handling the values of X-Forwarded-For based on IP address.
The public frontend logs are only visible to the hoster, so full control at that layer does involve self-hosting a zrok instance, yes.
Here's what a zrok.io public frontend passed through to my test webserver with a public share backend in "proxy" mode. I visited the public share URL in Google Chrome browser.
I removed two headers because I'm unsure what their data represent, and they're probably not relevant: Cookie, X-Amzn-Trace-Id. I redacted the comma-separated list of user-agent IP addresses in X-Forwarded-For.
GET / HTTP/1.1
Host: ohoq1uqzftut.share.zrok.io
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-US,en;q=0.9
Cache-Control: max-age=0
Priority: u=0, i
Referer: https://ohoq1uqzftut.share.zrok.io/
Sec-Ch-Ua: "Not A(Brand";v="8", "Chromium";v="132", "Google Chrome";v="132"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "Linux"
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
X-Forwarded-For: ***,***
X-Forwarded-Port: 443
X-Forwarded-Proto: https
X-Proxy: zrok