I don't know exactly where the problem is exactly, so maybe someone smarter than me can give me some direction here.. 

 

I've got binhex-teamspeak isntalled. did a test connect to it locally and it was good so I bumped it over to "proxy-net" (thanks spaceinvader)  Created a new cname record: ts.mydomain.tech and made a new teamspeak.subdomain.conf file for Swag and made the necessary changes to the the Swag container.

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name ts.*;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    location / {
        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_app teamspeak;
        set $upstream_port 443;
        set $upstream_proto https;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

        proxy_max_temp_file_size 2048m;
    }
}

Swag starts fine, I get "Server Ready" which tells me there's no problem there. 

 

But I cannot connect to the server. Anyone got any suggestions?

Question, what ports does it actually need normally?

 

Looking at the forum it dosnt use 443? Looks to use 443 just for outbound communication? 

https://support.teamspeak.com/hc/en-us/articles/360002712257-Which-ports-does-the-TeamSpeak-3-server-use-

 

Looking at this post on the TS forums they seem to have alot more than just 443 in their configs?

https://community.teamspeak.com/t/teamspeak-3-reverse-proxy-nginx-wireguardvpn-ifs/3396/2

Why do you want to do that @2Piececombo?

Why? Well, partially just because I wanted to see if it was possible. And I figured it added a bit of extra security? 
 

I somehow overlooked the port thing, I'll see what I can do

You can run into trouble with this...

 

This is a server client application that uses it's own encryption (AES) and there might be some problems when do it like this since TeamSpeak needs multiple ports if you configure it fully and you also have to forward them.

 

Since you are running this in an "isolated" container there is not much of a benefit routing/proxying it through another container (added latency, compute power,...).

Fair enough. Was a fun experiment at the very least.

On 1/13/2021 at 12:13 PM, 2Piececombo said:

resolver 127.0.0.11 valid=30s;

Not sure if this is too late but was looking for a similar answer and wanted to check that 1 line? Shouldn't it be 127.0.0.1 unless this is something specific to unraid that I am not familiar with.