Jellyfin Works on Wi-Fi but Fails on Ethernet or VPN

Eva Wong

IceWhale author

Eva Wong is the Technical Writer and resident tinkerer at ZimaSpace. A lifelong geek with a passion for homelabs and open-source software, she specializes in translating complex technical concepts into accessible, hands-on guides. Eva believes that self-hosting should be fun, not intimidating. Through her tutorials, she empowers the community to demystify hardware setups, from building their first NAS to mastering Docker containers.

Jellyfin Works on Wi-Fi but Fails on Ethernet or VPN - Zima Store Online

If Jellyfin works over Wi-Fi but fails on Ethernet or through a VPN, the server is usually healthy; the path to it has changed. The most common branches are a different IP/subnet or DNS answer, a route that prefers the wrong interface, firewall/local-network rules that classify the connection differently, or a VPN route that overlaps the LAN.

Use one known-good Jellyfin URL and test from the affected client in layers. First prove the destination IP and port, then compare routes, then check firewall and Jellyfin Local Networks, and only after that inspect VPN-specific subnet or exit-node behavior. Do not reinstall Jellyfin while the same server is reachable over another interface, because that evidence already points to networking rather than application state.

Compare the Destination Address on Wi-Fi and Ethernet

On the working Wi-Fi connection, record the Jellyfin hostname, resolved IP address, client subnet, and port. Move to Ethernet and repeat the same checks. If the hostname resolves to a different or unreachable address, fix DNS or the client route before touching Jellyfin settings.

Jellyfin's networking documentation explains that normal access uses the host IP and configured HTTP(S) port, while local discovery is limited to the local subnet. Review the local network behavior when a wired client sits on a different VLAN or subnet from the Wi-Fi network.

Test the server IP directly from Ethernet. If the IP works but the hostname fails, the branch is DNS. If neither works, continue to route and firewall checks; if the TCP port connects but the app behaves differently, inspect Jellyfin's local/remote classification.

Check Which Interface and Route the Client Is Actually Using

A machine with Wi-Fi, Ethernet, and VPN adapters can keep several routes at once. When Ethernet is connected, the operating system may prefer a new default route or a more specific subnet route that sends Jellyfin traffic somewhere different from the working Wi-Fi path.

Inspect the route to the Jellyfin server IP using your operating system's routing tools and compare it with the working state. Disable only one interface temporarily to prove the branch, then re-enable it; do not permanently delete routes until you know which rule is wrong.

If the route points to the correct Ethernet gateway and the server is reachable by ping but the Jellyfin port fails, the next test is firewall or service binding rather than DNS.

Verify Firewall Rules and Jellyfin Local Networks

Compare firewall policy for the Ethernet subnet, VPN subnet, and Wi-Fi subnet. Home routers and managed switches often apply different VLAN or guest-network rules even when all three connections are physically inside the same home.

In Jellyfin, review the Local Networks CIDR values and remote-access policy. A client arriving from an unlisted subnet can be treated as remote, which may change whether access is allowed for that user even though the server is listening normally.

For a broader example of separating local success from remote-path failure, see local versus remote access paths. The same discipline applies here: prove each network hop before changing the application.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

Look for VPN Subnet Overlap or Exit-Node Behavior

When the failure appears only with a VPN enabled, compare the VPN routes with the physical LAN. Two networks that use the same private subnet can cause the client to send Jellyfin traffic into the tunnel even though the server is physically nearby.

Tailscale documents cases where subnet routes, exit nodes, or LAN access settings can prevent a client from reaching a local device. Use its LAN connectivity troubleshooting as an example of how VPN routing can override the path that worked before the tunnel was enabled.

Temporarily disable VPN route acceptance or the exit node and retest the same Jellyfin IP. If access immediately returns, keep the Jellyfin server unchanged and correct the VPN routing or LAN-access policy instead.

Re-Test the Original Client Path After Each Network Fix

Once you identify the branch, apply only the matching change: correct DNS, adjust route metrics or prefixes, permit the Ethernet/VPN subnet in the firewall, or fix Jellyfin's Local Networks entry. Then restore all normal interfaces and repeat the original connection method.

Verify both the Jellyfin web client and one native client if your household uses both, because discovery, saved server URLs, and direct HTTP access can follow different paths. Also test after a client reboot or reconnect so cached routes do not make a temporary success look permanent.

Escalate only if the destination IP, route, firewall, and Local Networks classification are all correct but the same interface still fails. Capture the working and failing route tables, client IPs, and server logs from one attempt; that evidence is far more useful than reinstalling Jellyfin or resetting all network settings at once.