groot-stuff

That is the entirety of the abc.subdomain.conf file for my unraid subdomain located in /mnt/user/appdata/swag/nginx/proxy-confs/ You may have a slightly different path to the proxy-confs folder though, depending on your setup.

I quoted part of my post from way earlier in the thread, the next thing I'd suggest is capturing some packets to inspect/investigate with WireShark or similar tool. Just switch out the IP in the command below for the one of the machine you are using to SSH into unRaid with. Then take the .pcap file into WireShark and see if there are any oddities, feel free to share the .pcap if you'd like (DM it so you don't have to post potentially identifying IP info to the world). tcpdump -i any -nn -t -e dst not 192.168.0.254 and src not 192.168.0.254 -w unraid.pcap Refer to my older post for more info/instruction. Definitely make sure to reduce network traffic to clean up the tcpdump (turn off Dockers & VMs). https://forums.unraid.net/topic/96835-dns-resolution-issues/?do=findComment&comment=892657

What address are you pinging... a domain or an IP? Are the results of these two commands the same? and same initial delay? ping ns1.google.com ping 216.239.32.10 Are the VM's being assigned their own IP addresses? Same subnet as host unRaid machine? Are they assigned the same or different DNS servers?

After resetting my Plex account password I ran into this same issue. Solved it by doing 2 things: 1. Following the Remove Certain Entries > Linux instructions at this link (delete 4 PlexOnline attribute/key pairs from Preferences.xml file) https://support.plex.tv/articles/account-requires-password-reset/ 2. Following the Sign In/Claim Your Plex Media Server > Docker instructions at this link (to generate a new claim token) https://support.plex.tv/articles/account-requires-password-reset/ Once I updated the claim token in the docker's config and clicked Apply, the docker restarted. I immediately went to http://unraidIP:32400/web in an incognito browser and signed in. Everything was restored and no further action was needed. Signed back in through a normal Chrome browser and I am 100% back to expected functionality.

This is what I've got configured and the progress UI updates, but at a much slower rate than without using the reverse proxy (maybe every 15-30 secs), so often times the entire docker update is completed by the time it updates. When installing/updating larger dockers (like Android Studio) I can see the progress updates come through mid-process. server { listen 443 ssl; listen [::]:443 ssl; server_name unRaidSubdomain.*; include /config/nginx/ssl.conf; client_max_body_size 0; # https://forums.unraid.net/topic/73158-progress-ui-not-working-through-reverse-proxy/page/2/ gzip off; proxy_buffering off; # enable for ldap auth, fill in ldap details in ldap.conf #include /config/nginx/ldap.conf; # enable for Authelia #include /config/nginx/authelia-server.conf; location / { # enable the next two lines for http auth #auth_basic "Restricted"; #auth_basic_user_file /config/nginx/.htpasswd; # enable the next two lines for ldap auth #auth_request /auth; #error_page 401 =200 /ldaplogin; # enable for Authelia #include /config/nginx/authelia-location.conf; include /config/nginx/proxy.conf; proxy_pass https://[unRaidIP]; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "Upgrade"; } } Its been a while, but I think these are all of the additions I made when I was messing with it... In the server block: gzip off; proxy_buffering off; In the location block (my webui is set for HTTPS only): proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "Upgrade";

Trying to help here but you'll need to provide more information than just symptoms... What DNS servers are you using? Have you tried others? Which ones? How long after a reboot can you resolve a domain? Minutes, hours, days? Are you using an ISP provided modem/router or have your own equipment? Do you have any "safe browsing" or security services included from your ISP? (like the person above) Are you running through any VPN or proxy connections/services? Are you able to ping 8.8.8.8 from the terminal when the problem is occuring? (that would rule out a more general loss of connectivity) What other troubleshooting steps have you tried aside from just rebooting?

Possible, but unlikely if it is only Sonarr. Would need more information to help troubleshoot, which Sonarr container you are using for starters. Also, rather than rebooting your whole server, have you tried just restarting the container? Verifying a DNS resolution issue with one container would also require getting into it's own shell, are you familiar with that? (it's easy after setting up the docker-shell script) If it's binhex's Sonarr container I would highly recommend shifting your dialog to his support thread here. Occasionally I see indexers not working in Sonarr/Radarr simply because the API's limit has been reached for whatever "request per time period" it is restricted to. Nothing to fix that particular issue aside from waiting. Have you check for errors under System > Status & System > Log Files?

It is entirely possible that your ISP is blocking outbound requests on port 53 (DNS). Quoting that answer so you don't have to click the link... "Yes, they can block custom DNS - and its fairly trivial. All they need to do is block port 53 exiting their network (except from their nameservers - but in practice its more likely to be from their broadband IP ranges) The logical reasons for doing this include (which I vehemently disagree with, but thats besides the point) tracking usage, forcing traffic to local caches, blocking access to certain sites, injecting adverts instead of errors for non-existent domain names. There could theoretically also be benefits to you (prevent some kinds of malware, faster DNS resolution times for people with wrong DNS settings)" To test if they are, just run this at the terminal: telnet 8.8.8.8 53 If it times out/fails to connect then your ISP is blocking outbound requests on port 53. This is what my successful result looks like (not blocked):

Wow... 10gig - impressive for in-the-home speed availability! 💪 I'm not sure if I mention this anywhere, but the one thing that did change in my setup was the firewall (but not the config). Went from an old Zyxel USG50 to a Zyxel VPN100... maybe some differences in the firmware that cause it to handle DNS requests differently. I have updated the VPN100's firmware a couple times since this issue but haven't bothered to take my array offline to test going back to using OpenDNS rather than my router's IP for the DNS entry in unRaid. As far as ISP, I've always been on a dual-WAN setup through a basic Arris coax modem (SB6141 before, SB8200 now) and Zyxel firewall (USG50 before, VPN100 now), with 1gig (now 1.2gig) Xfinity/Comcast as the primary and CenturyLink/Level3 as failover-only (no round robin or least-load-first because clink is SO slow (20/1Mbps)). If you don't have much configurability with the ISP provided fiber box... have you tried altering the DNS entries within unRaid (Settings > Network) to test using public DNS options as well as your default gateway/fiber box IP?

What worked for me was (strangely) setting the first DNS entry to my router's default gateway... typically something like 192.168.1.1 unless you have a custom subnet setup. Worth a try - but IMO setting up a custom network is more fun than using ISP provided equipment. ☺️

Did you fix the typo? See the blue text in my post above

Please provide the DNS entries you see when using both of the configurations... the finest details can be the culprit with these types of issues (see my post above for all I went through) These can be acquired from Settings > Network Settings or the results from cat /etc/resolv.conf at the command line

The recommended setup in many other places is to only use public DNS servers and remove all entries for your router. Honestly this is what I prefer, but my new firewall of the same brand is acting subtlety different. So the first thing I would try is using only public DNS servers, i.e. just 208.67.220.220 208.67.222.222 Actually... looking closer at your screenshot, your 2nd entry (1st external IP) has a typo (222.220 should be 220.220). Hopefully its that simple, but if not... What do you have starting with the array? I'd suggest testing these independently... Dockers set to auto-start Settings > Docker > Enable: Yes/No If disabling the Docker service works, continue testing by enabling one Docker at a time, testing after each one VMs set to auto-start Settings > VM Manager > Enable VMs: Yes/No UserScripts plugin with a script set to run on array start Change schedule(s) to "Schedule Disabled" Also think about any other custom scripts or configurations you may have. For example... custom docker networks or ip routing rules. I would also suggest getting into the shell of a docker container and trying the DNS lookups from within it. This is where I isolated my issue because the docker network uses a different DNS resolver/address (127.0.0.11 with my config). Guide to setup docker-shell'ing:

Have you tried setting your DNS in the unRaid webui to external DNS servers (Google, OpenDNS, etc.)? If you have tried external without success, also try setting them to your router (typically the default gateway address a.k.a. your routers IP address) - this solved it for me, strangely. Please give more info of your config, symptoms and troubleshooting already completed for the community to provide assistance (rather than guesses). Lastly, I wrote an extensive post about the troubleshooting I did here:

Necro post with value below, as this is the top Google result on the topic. bulldozer !'s question on @SpaceInvaderOne's recent video (How to Test the Speed inside a VPN Download Container: https://www.youtube.com/watch?v=m7Qly7a_-M0) prompted this post. WARNING! EDITING THE sudoers FILE (OR ANY FILE THAT FEEDS INTO IT) INCORRECTLY CAN CAUSE IRREPERABLE DAMAGE AND POSSIBLE LOSS OF ACCESS TO YOUR SYSTEM! YOU HAVE BEEN WARNED. Only use visudo to edit the sudoers file (or any file that feeds into it)! visudo performs checks to aid in correct sudo file formatting (it is not fool-proof, double check your formatting!). Learning vi/visudo is on you, Google it for plenty of resources! https://lmgtfy.app/?q=how+to+use+visudo+in+linux Also, I am no Linux expert, but have used this method to successfully add a user to the sudoers list - on boot. Okay, now that the disclaimers are over... lets check out a more complete explanation of adding a user to the sudoers list without the use of any additional tools/plugins (UserScripts is great btw, I use it heavily on my server). Understand that sudo access can be dangerous, do not give this to users who do not understand it's power The /etc/sudoers file itself does not need to be edited, by default it will include the /etc/sudoers.d/ directory (below is a snippet of the end of the sudoers file) ## Read drop-in files from /etc/sudoers.d ## (the '#' here does not indicate a comment) #includedir /etc/sudoers.d Create a file named sudoadd (no .extension), using visudo, in /boot/custom/ /boot/ is your flashdrive, storing the file here allows it to survive reboots and unRaid to access it while booting up You may need to create the /boot/custom/ subdirectory I had the subdirectory after following Spaceinvaders video on setting up the docker-shell script Add the following to the sudoadd file (adjusting USERNAME to the one you'd like to use) ## ## User privilege specification ## USERNAME ALL=(ALL) NOPASSWD: ALL This is in the format of root's section in the /etc/sudoers file NOTE: the "NOPASSWD: " is not required and allows the specified user to execute the sudo command without entering a password Again, this is another dangerous setting... see this article for more info: https://www.tecmint.com/run-sudo-command-without-password-linux/ If you prefer to enter a password when using the sudo command, just remove "NOPASSWD: " The resulting line (password required) would read as: USERNAME ALL=(ALL) ALL Write the file and Quit (generally ESC > : > wq > ENTER in visudo) Next we need to tell unRaid to move the custom file and set it's permissions appropriately in the go file AGAIN, BE CAREFUL - THE GO FILE IS VERY IMPORTANT, IT STARTS YOUR WEBUI! Add the following to the end/bottom of the go file located at /boot/config/go cp /boot/custom/sudoadd /etc/sudoers.d/sudoadd chmod 0440 /etc/sudoers.d/sudoadd The first line copies the custom sudoadd file from the flash drive to the OS files running in memory The second line changes the permissions on the copied file to what Linux expects for a system file (IIRC) Also add the following to the end/bottom of the go file chsh -s /bin/bash USERNAME This line changes the shell for the USERNAME you specify, allowing the user to login via SSH I use vi to edit the go file, so Write the file and Quit (generally ESC > : > wq > ENTER) If you're using another editor, save the go file and exit Reboot your server and test that the USERNAME you setup above can: Login via SSH Execute the sudo command P.S. I normally give full credit via links to sources where possible, but I researched and successfully did this a very long time ago. That aside, this thread and @SpaceInvaderOne were definite contributors of my solution. If something in this post needs to be clarified please reply or message me and I will update it