What's new

Register Now! Find useful tips, Interact /w Community Members and join the part the Best Community on the Internet!

Getting DNS_PROBE_FINISHED_NXDOMAIN for oath on Remote Server


Junior Member
PG Version
Server Type
Remote - VPS
So, I saw another recent thread about this, but it was almost 3 weeks old and I didn't want to necro it. If I should have, please remove or merge as you see fit. There is a difference between the two which is that their problem seemed to be related to a local server whereas my server is remote. However, once I've Deployed Traefik, Closed the Ports, and then deployed PGShield, my oath requests push back the NXDOMAIN error. I assume everything else is configured correctly because I can exempt Portainer and pull it up without issues. I configured everything yesterday and am still experiencing the problem 24 hours later, so I don't think caching is the issue either. I'll throw down some info below and if anything else is needed, just let me know.

Server Host: Contabo
Domain Registrar: Google
DNS: Cloudflare

All containers seem to check in running or healthy.

I am a little bit of a n00b, but I've been messing around with Linux on a superficial level for a couple years, now.

Also, I did, previously try this on a GCE machine, but couldn't get it set up there, either. That was SEVERAL days ago.


Full Member
Go back to Traefik and double check your deployment. Mine sometimes needs to be done again after PGShield launches. Yours might say deployed incorrectly


Junior Member
Well, opened up the menu for Traefik and it said it was DEPLOYED with no indication of any issues. That said, I went ahead and redeployed it, anyway.
It did not throw any errors, but I'm still getting
This site can’t be reached
oauth.mydomain.net’s server IP address could not be found.



Full Member
I have run across this error before. Let me know if this does not make sense at first. I applied PG Shield as an app instead of doing it via WEB. I would be logged in for machines that I was logged in already but I would get that error on machines that I was not logged in via a cookie. I verified this by deleting the history on a machine that I was already using and it was working correctly before deploying a fix.

I went back to the PGShield Wiki and did everything like I had never done it before and realized I was not clicking the WEB app radio button for it in my developer's console. This is what solved a similar issue I had during one deployment before.

Again, I don't know if this made complete sense because I ready something similar without it actually sinking into my skull the first time. I might be able to say it differently if this doesn't help you out tonight.


Junior Member
Double checked it, just now, and looks like it is, in fact, a Web credential thingie. Is there a benefit to ripping it out and trying to recreate it?
Assists Greatly with Development Costs


Did you add a cname for oauth in your DNS?? That's what the error is about lol


Junior Member
So, I had an A record. I converted it to a CNAME record last night, then enabled Shield just now and tested, but still getting the same thing.


Go through the PGShield wiki. You have to add your domain to the authorized domains list and add authorized redirect url too. It's a configuration issue on your end as PGShield hasn't changed and works fine.


Junior Member
I don't mean to imply anything of the sort. I'm certain it's a configuration error on my end, I just don't know what. I'll go back through the wiki and see if anything looks wrong.

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Similar threads

Top NZB NewsGroups!

Members - Up To a 58% Discount!

Development Donations


Online statistics

Members online
Guests online
Total visitors