I'm running Jellyfin in Docker on Ubuntu, managed with a Compose-style YAML file. Local playback is smooth, but remote users experience buffering, lag, and stuttering. Jellyfin shares the WireGuard container's network namespace using `network_mode: service:wireguard`, and both the local port and an AirVPN forwarded port are directed to Jellyfin's port 8096.
The WireGuard container uses AirVPN, full-tunnel routing with `AllowedIPs = 0.0.0.0/0, ::/0`, an MTU of 1320, and iptables rules that redirect the forwarded VPN port to Jellyfin. I also added a route and firewall rule intended to keep traffic from the local `192.168.39.0/24` network outside the VPN.
I'm wondering whether this is a sensible architecture for remote Jellyfin access. Could the VPN encryption, routing, MTU, or port-redirection setup be causing the poor remote performance? Is there a way to use AirVPN more like a high-bandwidth tunnel while avoiding unnecessary overhead, or would a different tunnel or reverse-proxy design be more appropriate? I'd like to understand what should be changed before publishing a complete working configuration.
2 Answers
WireGuard already is the tunnel, so there isn’t a separate mode that removes its encryption while keeping the same connection. AirVPN can provide a forwarded endpoint, but all traffic still goes through the VPN server and is limited by the path, server load, and your upload bandwidth. The overhead is usually small; transcoding, insufficient upload speed, packet loss, or an MTU problem are more common causes of Jellyfin stuttering.
Before changing the architecture, test the connection with a large file or a bandwidth tool through the forwarded port. Check Jellyfin’s dashboard to see whether the stream is direct playing or transcoding, and verify that the server has enough CPU/GPU resources for the selected video. Also test MTU values such as 1280, 1360, and 1420, since fragmentation over a VPN can hurt sustained video traffic.
The container layout is valid, but `network_mode: service:wireguard` means Jellyfin uses the WireGuard container’s network stack. Consequently, every published port and every routing rule must be configured on the WireGuard service. Make sure the forwarded AirVPN port is actually assigned to the current VPN connection and that the provider forwards TCP traffic to the same port you redirect.
Full-tunnel `AllowedIPs` also sends outbound traffic through AirVPN. The local-network bypass needs to be verified from inside the WireGuard container; a route using the default gateway may not behave as expected in the container namespace. Compare playback over the local address, the VPN endpoint, and a direct LAN-to-server test. If local playback is fine but the VPN path is slow, the bottleneck is likely the VPN route or its MTU rather than Jellyfin itself.
That helps clarify the design. I was hoping AirVPN could act more like a selectable transport with guaranteed bandwidth, but I understand that the encryption and provider routing are still part of the WireGuard connection. I’ll test the forwarded path and MTU before rebuilding everything.
A tunnel that does not encrypt the traffic would not provide the main security benefit of WireGuard. If the goal is only remote access, exposing Jellyfin through a properly configured reverse proxy or using a dedicated access tunnel may be simpler, but it still cannot create bandwidth that the VPN path does not have.