EDACerton

You removed these lines from /boot/config/go, put them back at the end:

# Start the Management Utility /usr/local/sbin/emhttp

The general diagnostics don't include Tailscale-specific data, but I'm going to take a guess here that you might have run a command that looks like this at some point:
 
tailscale serve - or - tailscale funnel  
Those commands will cause Tailscale to run a reverse proxy on port 443, which then interferes with the WebGUI.
 
If you're not sure, you can run this:
tailscale serve status  
If that shows that serve is enabled, you need to turn it off:
 
tailscale serve reset tailscale funnel reset  
 

I see the issue with this container.
 
It has a mapping for "Docker Socket", but instead of mapping /var/run/docker.sock, it is mapping the entirety of /var/run.
 
/var/run/tailscale/tailscaled.sock is the socket that Tailscale uses to communicate with itself. This means that the container is mapping the host socket into the container, which then causes the chaos you have encountered.
 
If you remove the mapping for /var/run and replace it with one for /var/run/docker.sock, it should work better. (Or, if you're not using the Docker socket for anything, just remove the mapping.)

Yes, this is one of the key benefits of Tailscale -- you don't have to open ports in the router. In general, the plugin is sufficient, unless you want to share specific containers with other tailnets. (e.g., if you wanted to give a friend access to a single container, but not be able to see everything). No, you don't need a separate network in Unraid. No, you don't have to set Tailscale up as a subnet router -- you can  connect to your services via http(s)://tailscaleIP:port/, just like you would http(s)://localIP:port/.

If you're already using Compose, I would recommend using either TDSProxy or Tailscale sidecar containers instead of trying to invoke the Tailscale injection provided by Unraid 7. Either of those tools are better/safer than trying to modify containers on the fly.

The MX500 drive is flooding the logs with failures. The drive is offline, and not reporting SMART data, so I would start with reseating/replacing the cables for it.
 
Once the drive is stable (and assuming that it somehow didn’t get removed from the pool configuration entirely), you should be able to run a scrub to repair the data on the drive.
 
Although, personally I'd probably just remove the MX500 from the pool, blkdiscard it, then add it again and scrub to give myself a little more confidence about the drive. That might just be me though

I noticed that you have a static IP address assigned of 192.168.0.103. Do you have a static reservation for that IP set in the DHCP settings on your router too?
 
The issues that you're describing sound like things that can happen if another device is trying to use the same IP. That IP would also generally be in the default IP pool of most routers, so it's possible that the router handed it to another device, and now the two devices fighting each other.