Coming from an issue from Github (Issue with Individual Connection via Reserved env · Issue #719 · openziti/zrok · GitHub)
Github Summary: Individual user given ERR_CONNECTION_RESET error when connecting to Reserved Front End Point created via foundryvtt-zrok-bootstrapper script. When using random public address via "Zrok Share...", user does not receive issue. Looking for solution to retain Reserved Enviroment link.
To better detail the situation, my group is comprised of people from around the us, mostly localized in one state. The individual member having the issue is outside our main state, but we have another member of the group in the same city as them which isn't having the issue. I am currently using foundryvtt-zrok-bootstrapper from @dovholuknf, to create the permalink "https:/(Env ID)foundryvtt.share.zrok.io/" which is having the issue.
With some manual testing, it was determined that the player could connect when using the link created by the command "zrok share public localhost" however disabling and creating a permalink with a new (Env id) repeated the issue. *Individual is at home not a public space, however I am unsure if they have some endpoint protection software.
Help on this would be appreciated as I would like to keep a permalink.
Hi @OccultistofOrion, welcome to the community and to zrok (and OpenZiti)!
This is really strange that they're able to access an ephemeral share, but not a reserved share. Really strange...
When you see the ERR_CONNECTION_RESET -- that is something the browser is showing the user, right? Like, that's the chrome(ium) error?
Could you (or the user) open a new tab, open dev tools (F12 or settings menu->more tools->developer tools) and then go to the share? I'm really interested to see if any errors show up in the console or if any red rows show up in the 'network' tab. Specifically, I'm wondering what the response code might be (if one is shown).
I've never seen this before and it sounds quite strange, particularly if an ephemeral share works.
I've seen endpoint protection software terminate connections it thinks are dubious before. My inclination is that something is triggering that. Only one user has this issue right ? Everyone else connects fine? Is the one user the "last user" to connect? I ask, because we've seen that Foundry VTT makes MANY requests for assets on the first connection. It might be possible that the user is just unlucky and getting throttled?
There's nothing useful on the zrok side whatsoever I assume, right? nothing shown in the terminal that might have a log?
Could you send an email to ziggy at zrok.io with your email address and the user's IP address so that we could look on our side through our logs?
This will be tough to debug since it seems to be limited to only one person. 
Cheers
I wonder if the difference in naming is somehow implicated in this?
Issues on the user end will have to wait, they left on travel.
What I can confirm is that it is only this user, it does not change based on load order. We've also had them test it on a vpn, different browsers (both chromium and FF), and other devices they own (while on their network), none of the cases worked. Network throttling also doesn't appear to cause issues when connecting either, based on dev settings (while throttled via settings, others are able to connect and join).
In terms of Zrok, typically I would see /join when anything pulls the link, including discord when it embeds the site name. However, when this user attempts the link, nothing comes up on their end.
Thank you for the support, Ill properly get all the data to you when they return.
Really, really strange! So it's seems to be "site" related then if more than one device has the problem? I'd be interested in what result they get if they use their cell phone off their home wifi. I'm also wondering if this is somehow IPv6 related or .... or maybe the exit IP of their server is blocked on our side. That'd definitely explain it if that were the case.
@michael.quigley published this post recently zrok is Growing Up and in it, we've had to come up with an idea how to avoid malicious sites using zrok. (People just can't be 'cool' and are using zrok to try to phish users, etc)... It'll be useful to collect their IP address so we can see if their IP is blocked for "reasons"...(Although, if ephemeral shares worked, that probably rules this idea out... grrr...)
Ok, we'll look for more info after they're back from travelling... (though having them test it when they are travelling would be nice too since that'd rule out their location!!! hahahah)
I've also had them test the link while modifying the token-name belonging to the script. The variations being "https:/(Env ID)foundry.share.zrok.io/)" and "https:/(Env ID)vtt.share.zrok.io/)". Neither worked but I did not try a tokenless url.
Just got a confirmation, the site now does load even though they're now farther away in another country on their phone using mobile data.
It's making me wonder if the ISP is somehow "doing something"... We'll have to wait until they're back at the normal location... It does seem to narrow it down to somehow being something specific to their site though, right?
Seems so, which was my running hypothesis though again the vpn and ephemeral share results threw that into question.