Zrok breaks when proxy turned on for ziti subdomain

Hi I am new to zrok and open ziti. I have been trying to self-host ZROK on a VPS, following the guide at Self-hosting guide for Docker | Zrok.

I want to have my computer at home access this ZROK instance on the VPS and then do public shares. I also have Cloudflare, where I own a domain, xyz.com, and I have the domain and the wildcard *.xyz.com proxied both to the VPS IP. In Cloudflare, I have SSL encryption on Full (strict).

The command I am running on my home computer is zrok share public localhost:3000. It works great if I turn off the proxy for specifically only the subdomain "ziti.xyz.com". The problem is I want to proxy all subdomains of xyz.com and the xyz.com domain.

When I turn on the proxy for the ziti.xyz.com subdomain and then try to do the share public command I get this error in my client

 zrok share public localhost:3000
[ERROR]: error creating proxy backend (error listening: failed to listen: no apiSession, authentication attempt failed: Post "https://ziti.xyz.com:80/edge/client/v1/authenticate?method=cert": http: server gave HTTP response to HTTPS client)

What is interesting though is that I can see these instances get created on
zrok.xyz.com in real time when I hit the share command. None of these share links on this site work because there is no connection to my home computer.

I use HTTPS turned on, and below is how my Cloudflare proxy is set up. This works great until I turn on the proxy for the ziti.xyz.com subdomain

How can I proxy this Ziti subdomain? Is there some configuration option I need to do?

Hi @goku, welcome to the community and to zrok (and OpenZiti/BrowZer)!

Thanks for the details, assuming I understand you (which I might not) it sounds like you're using cloudflare to proxy https. That will never work with zrok/OpenZiti if you're trying to self-host. That allows Cloudflare to decrypt/reencrypt your traffic and OpenZiti won't allow that. zrok itself is an https proxy. When you self-host zrok, it will do tls termination and send your traffic where it needs to go.

I think that answers the question, but if I misuderstand somehow, please correct me.

1 Like

Hi @TheLumberjack thank you for the quick response.

Yes, that is correct, I am using Cloudflare to proxy all the HTTPS (domain of xyz.com and wildcard *.xyz.com) requests that are incoming to my VPS

I see it looks like it is not possible with Cloudflare (at least the free plan). That is fine, I was hoping it could be possible so I can hide the IP address of my VPS.

If someone were to ping the Ziti subdomain they can see my VPS IP Address. I will just have to protect my VPS in another way.

Thank you!

You can use CloudFlare "orange cloud" proxy for the zrok-controller (zrok.${ZROK_DNS_ZONE}) and zrok-frontend (*.${ZROK_DNS_ZONE}), but it's a little tricky! If you decide it's OK for your VPS public IP to be unobscured for the OpenZiti parts of the system, then I'll assist with the CF Proxy details.

@TheLumberjack is correct, you must not use the CF proxy to provide TLS or IP obfuscation for the ziti-quickstart (ziti.{$ZROK_DNS_ZONE}) domain name when following the Docker instance guide. You can set that A record to the VPS public IP so it connects directly from each zrok environment.

Hi @qrkourier, I am currently using the orange cloud proxy for Zrok and the wildcard subdomain.

I just have the ziti.xyz.com domain unproxied. I did not do anything else, and everything seems to work fine. This means that when I ping Zrok or any subdomain other than the Ziti subdomain, I see a Cloudflare IP address.

Also, these lines looked insecure so I removed them and my Zrok instance still works fine: zrok/docker/compose/zrok-instance/Caddyfile at bcb00b11f5994cf3563fbfa6f6ade886b6e0110e · openziti/zrok · GitHub

Please let me know if there is anything I am missing or should do.

1 Like

That's great! Thanks for confirming it's working.


The Caddyfile stanza you removed is optional. It's purpose is to provide a trusted server certificate for the OpenZiti console, which you probably won't ever need anyway. It seemed like a good idea at the time. :slightly_smiling_face:

	# ziti administration console uses :443 for the benefit of a web UI cert and accesses the ziti edge-management API
	@ziti host ziti.{$ZROK_DNS_ZONE}
	reverse_proxy @ziti ziti-quickstart:{$ZITI_CTRL_ADVERTISED_PORT:80} {
		transport http {
			tls_insecure_skip_verify
		}
	}

The tls_insecure_skip_verify is necessary only if you wish to enable access to the OpenZiti console through Caddy. It's because Caddy doesn't trust OpenZiti's certificate, which is expected.

1 Like