Cannot access Jellyfin after updating to 10.9 - possible binding problem #5690

Closed
opened 2026-02-07 02:06:09 +03:00 by OVERLORD · 36 comments
Owner

Originally created by @carden-jeremy on GitHub (May 12, 2024).

Describe The Bug
Everything was fine until I upgraded to 10.9. Now, I cannot connect to my Jellyfin anymore. I keep getting these messages in the log when I try to connect:

[2024-05-11 20:56:25.591 -04:00] [WRN] [26] Jellyfin.Networking.Manager.NetworkManager: "127.0.0.1": External request received, no matching external bind address found, trying internal addresses.
[2024-05-11 20:56:25.592 -04:00] [WRN] [26] Jellyfin.Networking.Manager.NetworkManager: "127.0.0.1": External request received, but no external interface found. Need to route through internal network.
[2024-05-11 20:56:25.593 -04:00] [WRN] [26] Jellyfin.Networking.Manager.NetworkManager: "127.0.0.1": Only loopback "127.0.0.1" returned, using that as bind address.

I normally access Jellyfin's web server using my personal domain: jellyfin.mypersonaldomain.com:8096. But since upgrading to 10.9, I can only access it using localhost:8096. I cannot even access it using the computer's IP address, 192.168.1.101.

It seems there's a problem where 10.9 isn't binding to all interfaces and addresses. I normally have the "Bind to local network address" box blank. But I have tried putting 192.168.1.0/24 in that box, but no change.

I have 192.168.1.0/24 in the LAN networks box.

I tried deleting network.xml and restarting the service, but no change.

Expected Behavior
After upgrading to 10.9, Jellyfin should continue to be accessible by all IP addresses and hostnames like before.

Logs
At one point while trying to fix this issue, I got this exception in my log. I don't know where "5000" came from because I never entered that port anywhere that I know of.

System.IO.IOException: Failed to bind to address http://localhost:5000.
 ---> System.AggregateException: One or more errors occurred. (An attempt was made to access a socket in a way forbidden by its access permissions.) (An attempt was made to access a socket in a way forbidden by its access permissions.)
 ---> System.Net.Sockets.SocketException (10013): An attempt was made to access a socket in a way forbidden by its access permissions.
   at System.Net.Sockets.Socket.UpdateStatusAfterSocketErrorAndThrowException(SocketError error, Boolean disconnectOnFailure, String callerName)
   at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
   at System.Net.Sockets.Socket.Bind(EndPoint localEP)
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketTransportOptions.CreateDefaultBoundListenSocket(EndPoint endpoint)
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketConnectionListener.Bind()
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketTransportFactory.BindAsync(EndPoint endpoint, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Infrastructure.TransportManager.BindAsync(EndPoint endPoint, ConnectionDelegate connectionDelegate, EndpointConfig endpointConfig, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerImpl.<>c__DisplayClass28_0`1.<<StartAsync>g__OnBind|0>d.MoveNext()
--- End of stack trace from previous location ---
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.BindEndpointAsync(ListenOptions endpoint, AddressBindContext context, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.Core.LocalhostListenOptions.BindAsync(AddressBindContext context, CancellationToken cancellationToken)
   --- End of inner exception stack trace ---
 ---> (Inner Exception jellyfin/jellyfin-web#1) System.Net.Sockets.SocketException (10013): An attempt was made to access a socket in a way forbidden by its access permissions.
   at System.Net.Sockets.Socket.UpdateStatusAfterSocketErrorAndThrowException(SocketError error, Boolean disconnectOnFailure, String callerName)
   at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
   at System.Net.Sockets.Socket.Bind(EndPoint localEP)
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketTransportOptions.CreateDefaultBoundListenSocket(EndPoint endpoint)
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketConnectionListener.Bind()
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketTransportFactory.BindAsync(EndPoint endpoint, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Infrastructure.TransportManager.BindAsync(EndPoint endPoint, ConnectionDelegate connectionDelegate, EndpointConfig endpointConfig, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerImpl.<>c__DisplayClass28_0`1.<<StartAsync>g__OnBind|0>d.MoveNext()
--- End of stack trace from previous location ---
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.BindEndpointAsync(ListenOptions endpoint, AddressBindContext context, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.Core.LocalhostListenOptions.BindAsync(AddressBindContext context, CancellationToken cancellationToken)<---

   --- End of inner exception stack trace ---
   at Microsoft.AspNetCore.Server.Kestrel.Core.LocalhostListenOptions.BindAsync(AddressBindContext context, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.DefaultAddressStrategy.BindAsync(AddressBindContext context, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.BindAsync(ListenOptions[] listenOptions, AddressBindContext context, Func`2 useHttps, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerImpl.BindAsync(CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerImpl.StartAsync[TContext](IHttpApplication`1 application, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Hosting.GenericWebHostService.StartAsync(CancellationToken cancellationToken)
   at Microsoft.Extensions.Hosting.Internal.Host.<StartAsync>b__15_1(IHostedService service, CancellationToken token)
   at Microsoft.Extensions.Hosting.Internal.Host.ForeachService[T](IEnumerable`1 services, CancellationToken token, Boolean concurrent, Boolean abortOnFirstException, List`1 exceptions, Func`3 operation)
   at Microsoft.Extensions.Hosting.Internal.Host.StartAsync(CancellationToken cancellationToken)
   at Jellyfin.Server.Program.StartServer(IServerApplicationPaths appPaths, StartupOptions options, IConfiguration startupConfig)

System (please complete the following information):

  • Platform: Windows 11
  • Browser: Brave
  • Jellyfin Version: 10.9.0
Originally created by @carden-jeremy on GitHub (May 12, 2024). **Describe The Bug** Everything was fine until I upgraded to 10.9. Now, I cannot connect to my Jellyfin anymore. I keep getting these messages in the log when I try to connect: ``` [2024-05-11 20:56:25.591 -04:00] [WRN] [26] Jellyfin.Networking.Manager.NetworkManager: "127.0.0.1": External request received, no matching external bind address found, trying internal addresses. [2024-05-11 20:56:25.592 -04:00] [WRN] [26] Jellyfin.Networking.Manager.NetworkManager: "127.0.0.1": External request received, but no external interface found. Need to route through internal network. [2024-05-11 20:56:25.593 -04:00] [WRN] [26] Jellyfin.Networking.Manager.NetworkManager: "127.0.0.1": Only loopback "127.0.0.1" returned, using that as bind address. ``` I normally access Jellyfin's web server using my personal domain: jellyfin.mypersonaldomain.com:8096. But since upgrading to 10.9, I can only access it using localhost:8096. I cannot even access it using the computer's IP address, 192.168.1.101. It seems there's a problem where 10.9 isn't binding to all interfaces and addresses. I normally have the "Bind to local network address" box blank. But I have tried putting 192.168.1.0/24 in that box, but no change. I have 192.168.1.0/24 in the LAN networks box. I tried deleting network.xml and restarting the service, but no change. **Expected Behavior** After upgrading to 10.9, Jellyfin should continue to be accessible by all IP addresses and hostnames like before. **Logs** At one point while trying to fix this issue, I got this exception in my log. I don't know where "5000" came from because I never entered that port anywhere that I know of. ``` System.IO.IOException: Failed to bind to address http://localhost:5000. ---> System.AggregateException: One or more errors occurred. (An attempt was made to access a socket in a way forbidden by its access permissions.) (An attempt was made to access a socket in a way forbidden by its access permissions.) ---> System.Net.Sockets.SocketException (10013): An attempt was made to access a socket in a way forbidden by its access permissions. at System.Net.Sockets.Socket.UpdateStatusAfterSocketErrorAndThrowException(SocketError error, Boolean disconnectOnFailure, String callerName) at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress) at System.Net.Sockets.Socket.Bind(EndPoint localEP) at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketTransportOptions.CreateDefaultBoundListenSocket(EndPoint endpoint) at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketConnectionListener.Bind() at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketTransportFactory.BindAsync(EndPoint endpoint, CancellationToken cancellationToken) at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Infrastructure.TransportManager.BindAsync(EndPoint endPoint, ConnectionDelegate connectionDelegate, EndpointConfig endpointConfig, CancellationToken cancellationToken) at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerImpl.<>c__DisplayClass28_0`1.<<StartAsync>g__OnBind|0>d.MoveNext() --- End of stack trace from previous location --- at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.BindEndpointAsync(ListenOptions endpoint, AddressBindContext context, CancellationToken cancellationToken) at Microsoft.AspNetCore.Server.Kestrel.Core.LocalhostListenOptions.BindAsync(AddressBindContext context, CancellationToken cancellationToken) --- End of inner exception stack trace --- ---> (Inner Exception jellyfin/jellyfin-web#1) System.Net.Sockets.SocketException (10013): An attempt was made to access a socket in a way forbidden by its access permissions. at System.Net.Sockets.Socket.UpdateStatusAfterSocketErrorAndThrowException(SocketError error, Boolean disconnectOnFailure, String callerName) at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress) at System.Net.Sockets.Socket.Bind(EndPoint localEP) at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketTransportOptions.CreateDefaultBoundListenSocket(EndPoint endpoint) at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketConnectionListener.Bind() at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketTransportFactory.BindAsync(EndPoint endpoint, CancellationToken cancellationToken) at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Infrastructure.TransportManager.BindAsync(EndPoint endPoint, ConnectionDelegate connectionDelegate, EndpointConfig endpointConfig, CancellationToken cancellationToken) at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerImpl.<>c__DisplayClass28_0`1.<<StartAsync>g__OnBind|0>d.MoveNext() --- End of stack trace from previous location --- at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.BindEndpointAsync(ListenOptions endpoint, AddressBindContext context, CancellationToken cancellationToken) at Microsoft.AspNetCore.Server.Kestrel.Core.LocalhostListenOptions.BindAsync(AddressBindContext context, CancellationToken cancellationToken)<--- --- End of inner exception stack trace --- at Microsoft.AspNetCore.Server.Kestrel.Core.LocalhostListenOptions.BindAsync(AddressBindContext context, CancellationToken cancellationToken) at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.DefaultAddressStrategy.BindAsync(AddressBindContext context, CancellationToken cancellationToken) at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.BindAsync(ListenOptions[] listenOptions, AddressBindContext context, Func`2 useHttps, CancellationToken cancellationToken) at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerImpl.BindAsync(CancellationToken cancellationToken) at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerImpl.StartAsync[TContext](IHttpApplication`1 application, CancellationToken cancellationToken) at Microsoft.AspNetCore.Hosting.GenericWebHostService.StartAsync(CancellationToken cancellationToken) at Microsoft.Extensions.Hosting.Internal.Host.<StartAsync>b__15_1(IHostedService service, CancellationToken token) at Microsoft.Extensions.Hosting.Internal.Host.ForeachService[T](IEnumerable`1 services, CancellationToken token, Boolean concurrent, Boolean abortOnFirstException, List`1 exceptions, Func`3 operation) at Microsoft.Extensions.Hosting.Internal.Host.StartAsync(CancellationToken cancellationToken) at Jellyfin.Server.Program.StartServer(IServerApplicationPaths appPaths, StartupOptions options, IConfiguration startupConfig) ``` **System (please complete the following information):** - Platform: Windows 11 - Browser: Brave - Jellyfin Version: 10.9.0
OVERLORD added the bug label 2026-02-07 02:06:09 +03:00
Author
Owner

@jellyfin-bot commented on GitHub (May 12, 2024):

Hi, it seems like your issue report has the following item(s) that need to be addressed:

  • This bug report was not filed using the issue template.

This is an automated message, currently under testing. Please file an issue here if you encounter any problems.

@jellyfin-bot commented on GitHub (May 12, 2024): Hi, it seems like your issue report has the following item(s) that need to be addressed: - This bug report was not filed using the issue template. This is an automated message, currently under testing. Please file an issue [here](https://github.com/jellyfin/jellyfin-triage-scripts/issues) if you encounter any problems.
Author
Owner

@TnZzZHlp commented on GitHub (May 12, 2024):

I have encountered the same issue as well

@TnZzZHlp commented on GitHub (May 12, 2024): I have encountered the same issue as well
Author
Owner

@bioblatt commented on GitHub (May 12, 2024):

same for me, web only shows the jellyfin logo and on android I also can't connect to the server

@bioblatt commented on GitHub (May 12, 2024): same for me, web only shows the jellyfin logo and on android I also can't connect to the server
Author
Owner

@Germs2004 commented on GitHub (May 12, 2024):

When I run netstat and filter for "Jellyfin", I get this:

C:\Windows\System32>netstat -a -b -n

Active Connections

  Proto  Local Address          Foreign Address        State
  TCP    127.0.0.1:8096         0.0.0.0:0              LISTENING
 [jellyfin.exe]
  UDP    0.0.0.0:7359           *:*
 [jellyfin.exe]

I think this means it's only listening on IP address 127.0.0.1 even though "Bind to local network address" is set to empty.

@Germs2004 commented on GitHub (May 12, 2024): When I run netstat and filter for "Jellyfin", I get this: ``` C:\Windows\System32>netstat -a -b -n Active Connections Proto Local Address Foreign Address State TCP 127.0.0.1:8096 0.0.0.0:0 LISTENING [jellyfin.exe] UDP 0.0.0.0:7359 *:* [jellyfin.exe] ``` I think this means it's only listening on IP address 127.0.0.1 even though "Bind to local network address" is set to empty.
Author
Owner

@gnattu commented on GitHub (May 12, 2024):

If you are on windows, can you check if your firewall actually allowed jellyfin?

@gnattu commented on GitHub (May 12, 2024): If you are on windows, can you check if your firewall actually allowed jellyfin?
Author
Owner

@Spicy-Jack103 commented on GitHub (May 12, 2024):

I am having the same issue - Windows firewall is turned off for both the client and server device and still has the same issue.

@Spicy-Jack103 commented on GitHub (May 12, 2024): I am having the same issue - Windows firewall is turned off for both the client and server device and still has the same issue.
Author
Owner

@Germs2004 commented on GitHub (May 12, 2024):

If you are on windows, can you check if your firewall actually allowed jellyfin?

I had the Windows Firewall completely disabled while troubleshooting. And the problem began upon updating to 10.9.0.

@Germs2004 commented on GitHub (May 12, 2024): > If you are on windows, can you check if your firewall actually allowed jellyfin? I had the Windows Firewall completely disabled while troubleshooting. And the problem began upon updating to 10.9.0.
Author
Owner

@TnZzZHlp commented on GitHub (May 12, 2024):

If you are on windows, can you check if your firewall actually allowed jellyfin?

The issue seems to stem from the fact that Jellyfin is unable to detect the IP address on my network adapter. I'm using Hyper-V and a Virtual Switch

@TnZzZHlp commented on GitHub (May 12, 2024): > If you are on windows, can you check if your firewall actually allowed jellyfin? The issue seems to stem from the fact that Jellyfin is unable to detect the IP address on my network adapter. I'm using Hyper-V and a Virtual Switch
Author
Owner

@Germs2004 commented on GitHub (May 12, 2024):

If you are on windows, can you check if your firewall actually allowed jellyfin?

The issue seems to stem from the fact that Jellyfin is unable to detect the IP address on my network adapter, which is a vEthernet adapter for Hyper-V.

Oh, that might be a pattern. I'm using Hyper-V and a Virtual Switch too, though Jellyfin is installed on the Host, not a VM.

@Germs2004 commented on GitHub (May 12, 2024): > > If you are on windows, can you check if your firewall actually allowed jellyfin? > > The issue seems to stem from the fact that Jellyfin is unable to detect the IP address on my network adapter, which is a vEthernet adapter for Hyper-V. Oh, that might be a pattern. I'm using Hyper-V and a Virtual Switch too, though Jellyfin is installed on the Host, not a VM.
Author
Owner

@gnattu commented on GitHub (May 12, 2024):

So let's confirm this:

All of you guys are on windows and are connected through Hyper-V vSwitch right?

@gnattu commented on GitHub (May 12, 2024): So let's confirm this: All of you guys are on windows and are connected through Hyper-V vSwitch right?
Author
Owner

@Germs2004 commented on GitHub (May 12, 2024):

So let's confirm this:

All of you guys are on windows and are connected through Hyper-V vSwitch right?

yes for me

@Germs2004 commented on GitHub (May 12, 2024): > So let's confirm this: > > All of you guys are on windows and are connected through Hyper-V vSwitch right? yes for me
Author
Owner

@Spicy-Jack103 commented on GitHub (May 12, 2024):

So let's confirm this:

All of you guys are on windows and are connected through Hyper-V vSwitch right?

Yes, that is correct. Jellyfin running the on Hyper-V server (NOT in a VM) but running through the Hyper V switch

@Spicy-Jack103 commented on GitHub (May 12, 2024): > So let's confirm this: > > All of you guys are on windows and are connected through Hyper-V vSwitch right? Yes, that is correct. Jellyfin running the on Hyper-V server (NOT in a VM) but running through the Hyper V switch
Author
Owner

@gnattu commented on GitHub (May 12, 2024):

If that is the case, can you try set <IgnoreVirtualInterfaces> key to <IgnoreVirtualInterfaces>false</IgnoreVirtualInterfaces> in the network.xml ?

From my testing disable that populates the vSwitch IP.

@gnattu commented on GitHub (May 12, 2024): If that is the case, can you try set `<IgnoreVirtualInterfaces>` key to `<IgnoreVirtualInterfaces>false</IgnoreVirtualInterfaces>` in the `network.xml` ? From my testing disable that populates the vSwitch IP.
Author
Owner

@Germs2004 commented on GitHub (May 12, 2024):

If that is the case, can you try set <IgnoreVirtualInterfaces> key to <IgnoreVirtualInterfaces>false</IgnoreVirtualInterfaces> in the network.xml ?

From my testing disable that populates the vSwitch IP.

That worked! Now I can access it by IP and the usual hostname. Thank you.

@Germs2004 commented on GitHub (May 12, 2024): > If that is the case, can you try set `<IgnoreVirtualInterfaces>` key to `<IgnoreVirtualInterfaces>false</IgnoreVirtualInterfaces>` in the `network.xml` ? > > From my testing disable that populates the vSwitch IP. That worked! Now I can access it by IP and the usual hostname. Thank you.
Author
Owner

@TnZzZHlp commented on GitHub (May 12, 2024):

If that is the case, can you try set key to in the ?<IgnoreVirtualInterfaces>``<IgnoreVirtualInterfaces>false</IgnoreVirtualInterfaces>``network.xml

From my testing disable that populates the vSwitch IP.

It works for me too. Thanks. but why it only happen on 10.9? it's a new option?

@TnZzZHlp commented on GitHub (May 12, 2024): > If that is the case, can you try set key to in the ?`<IgnoreVirtualInterfaces>``<IgnoreVirtualInterfaces>false</IgnoreVirtualInterfaces>``network.xml` > > From my testing disable that populates the vSwitch IP. It works for me too. Thanks. but why it only happen on 10.9? it's a new option?
Author
Owner

@gnattu commented on GitHub (May 12, 2024):

If that is the case, can you try set key to in the ? <IgnoreVirtualInterfaces>falsenetwork.xml
From my testing disable that populates the vSwitch IP.

It works for me too, but why it only happen on 10.9? it's a new option?

No, it is an old option, but in 10.8 there is a bug that this option does not actually ignore virtual interfaces like this.

@gnattu commented on GitHub (May 12, 2024): > > If that is the case, can you try set key to in the ?`` <IgnoreVirtualInterfaces>``<IgnoreVirtualInterfaces>false</IgnoreVirtualInterfaces>``network.xml `` > > From my testing disable that populates the vSwitch IP. > > It works for me too, but why it only happen on 10.9? it's a new option? No, it is an old option, but in 10.8 there is a bug that this option does not actually ignore virtual interfaces like this.
Author
Owner

@Germs2004 commented on GitHub (May 12, 2024):

Thankfully, there's a simple workaround, but can we get this setting exposed on the web GUI in a future version? Or have it set to false by default?

@Germs2004 commented on GitHub (May 12, 2024): Thankfully, there's a simple workaround, but can we get this setting exposed on the web GUI in a future version? Or have it set to false by default?
Author
Owner

@Spicy-Jack103 commented on GitHub (May 12, 2024):

Perfect! that does the job!
Thanks for the assistance and good work!

@Spicy-Jack103 commented on GitHub (May 12, 2024): Perfect! that does the job! Thanks for the assistance and good work!
Author
Owner

@Bizarre955 commented on GitHub (May 12, 2024):

If that is the case, can you try set <IgnoreVirtualInterfaces> key to <IgnoreVirtualInterfaces>false</IgnoreVirtualInterfaces> in the network.xml ?

From my testing disable that populates the vSwitch IP.

Fixed for me on box running hyper-v as well.

@Bizarre955 commented on GitHub (May 12, 2024): > If that is the case, can you try set `<IgnoreVirtualInterfaces>` key to `<IgnoreVirtualInterfaces>false</IgnoreVirtualInterfaces>` in the `network.xml` ? > > From my testing disable that populates the vSwitch IP. Fixed for me on box running hyper-v as well.
Author
Owner

@m4gicfour commented on GitHub (May 12, 2024):

If that is the case, can you try set <IgnoreVirtualInterfaces> key to <IgnoreVirtualInterfaces>false</IgnoreVirtualInterfaces> in the network.xml ?

From my testing disable that populates the vSwitch IP.

This was also the issue for me running on UNRAID.

@m4gicfour commented on GitHub (May 12, 2024): > If that is the case, can you try set `<IgnoreVirtualInterfaces>` key to `<IgnoreVirtualInterfaces>false</IgnoreVirtualInterfaces>` in the `network.xml` ? > > From my testing disable that populates the vSwitch IP. This was also the issue for me running on UNRAID.
Author
Owner

@spupuz commented on GitHub (May 12, 2024):

tried but not working i always got:

 Main: Kestrel failed to start! This is most likely due to an invalid address or port bind - correct your bind configuration in network.xml and try again

[12:01:23] [FTL] [1] Main: Error while starting server
@spupuz commented on GitHub (May 12, 2024): tried but not working i always got: ``` Main: Kestrel failed to start! This is most likely due to an invalid address or port bind - correct your bind configuration in network.xml and try again [12:01:23] [FTL] [1] Main: Error while starting server ```
Author
Owner

@Germs2004 commented on GitHub (May 12, 2024):

tried but not working i always got:

 Main: Kestrel failed to start! This is most likely due to an invalid address or port bind - correct your bind configuration in network.xml and try again

[12:01:23] [FTL] [1] Main: Error while starting server

I suggest renaming your Jellyfin/Server/config/network.xml file to network.xml.backup, then restart the Jellyfin service. That will reset your network settings to default. Then, go back to the Dashboard > Network settings, reconfigure things there, and restart the service again. If it still gets an error, do this again but only make one change at a time and restart the service between each change to see which setting is causing your error.

@Germs2004 commented on GitHub (May 12, 2024): > tried but not working i always got: > > ``` > Main: Kestrel failed to start! This is most likely due to an invalid address or port bind - correct your bind configuration in network.xml and try again > > [12:01:23] [FTL] [1] Main: Error while starting server > ``` I suggest renaming your Jellyfin/Server/config/network.xml file to network.xml.backup, then restart the Jellyfin service. That will reset your network settings to default. Then, go back to the Dashboard > Network settings, reconfigure things there, and restart the service again. If it still gets an error, do this again but only make one change at a time and restart the service between each change to see which setting is causing your error.
Author
Owner

@jumoog commented on GitHub (May 12, 2024):

tried but not working i always got:

 Main: Kestrel failed to start! This is most likely due to an invalid address or port bind - correct your bind configuration in network.xml and try again

[12:01:23] [FTL] [1] Main: Error while starting server

I suggest renaming your Jellyfin/Server/config/network.xml file to network.xml.backup, then restart the Jellyfin service. That will reset your network settings to default. Then, go back to the Dashboard > Network settings, reconfigure things there, and restart the service again. If it still gets an error, do this again but only make one change at a time and restart the service between each change to see which setting is causing your error.

No, network.xml is only created if the binding was successful.

@jumoog commented on GitHub (May 12, 2024): > > tried but not working i always got: > > ``` > > Main: Kestrel failed to start! This is most likely due to an invalid address or port bind - correct your bind configuration in network.xml and try again > > > > [12:01:23] [FTL] [1] Main: Error while starting server > > ``` > > I suggest renaming your Jellyfin/Server/config/network.xml file to network.xml.backup, then restart the Jellyfin service. That will reset your network settings to default. Then, go back to the Dashboard > Network settings, reconfigure things there, and restart the service again. If it still gets an error, do this again but only make one change at a time and restart the service between each change to see which setting is causing your error. No, `network.xml` is only created if the binding was successful.
Author
Owner

@gnannig commented on GitHub (May 12, 2024):

Same issue for me, Ubuntu 22.04.4 LTS.
Kernel 5.15.0-106-generic
removing network.xml doesn't fix (see jumoog's comment).
false already present in network.xml

@gnannig commented on GitHub (May 12, 2024): Same issue for me, Ubuntu 22.04.4 LTS. Kernel 5.15.0-106-generic removing network.xml doesn't fix (see jumoog's comment). <IgnoreVirtualInterfaces>false</IgnoreVirtualInterfaces> already present in network.xml
Author
Owner

@spupuz commented on GitHub (May 12, 2024):

Same issue for me, Ubuntu 22.04.4 LTS. Kernel 5.15.0-106-generic removing network.xml doesn't fix (see jumoog's comment). false already present in network.xml

Same situation for me with docker container

@spupuz commented on GitHub (May 12, 2024): > Same issue for me, Ubuntu 22.04.4 LTS. Kernel 5.15.0-106-generic removing network.xml doesn't fix (see jumoog's comment). false already present in network.xml Same situation for me with docker container
Author
Owner

@Schweppesale commented on GitHub (May 12, 2024):

I'm also experiencing the same issue.
The service will still listen in on port 5000 even with the following setting:
<IgnoreVirtualInterfaces>false</IgnoreVirtualInterfaces>


Renaming network.xml to network.bak.xml results in the following error on startup:
failed to load external entity "/config/network.xml"


update

It appears to be working as expected now after I updated the "Bind to local network address" setting.
I just changed it from 0.0.0.0 to 127.0.0.1

@Schweppesale commented on GitHub (May 12, 2024): I'm also experiencing the same issue. The service will still listen in on port `5000` even with the following setting: `<IgnoreVirtualInterfaces>false</IgnoreVirtualInterfaces>` ------ Renaming `network.xml` to `network.bak.xml` results in the following error on startup: `failed to load external entity "/config/network.xml"` ------ **update** It appears to be working as expected now after I updated the "Bind to local network address" setting. I just changed it from `0.0.0.0` to `127.0.0.1`
Author
Owner

@AlexLamond commented on GitHub (May 12, 2024):

It appears to be working as expected now after I updated the "Bind to local network address" setting. I just changed it from 0.0.0.0 to 127.0.0.1

@Schweppesale - How did you manage to update this without GUI access?

@AlexLamond commented on GitHub (May 12, 2024): > It appears to be working as expected now after I updated the "Bind to local network address" setting. I just changed it from `0.0.0.0` to `127.0.0.1` @Schweppesale - How did you manage to update this without GUI access?
Author
Owner

@spupuz commented on GitHub (May 12, 2024):

starting a new instance without config has not binding problems, but a wouild like to have my config working if possible.

@spupuz commented on GitHub (May 12, 2024): starting a new instance without config has not binding problems, but a wouild like to have my config working if possible.
Author
Owner

@gnattu commented on GitHub (May 13, 2024):

This original issue is about instances relying on veth to connect to outside, and for such instances, IgnoreVirtualInterfaces should be set to false as described previously.

We also have another issue caused by multiple networking interfaces sharing the same IP in #11557, this one is going to be resolved by #11587

If non of the above apply to you, please file a new issue with complete log and environment info so we can look it.

Closing as the original issue is resolved.

@gnattu commented on GitHub (May 13, 2024): This original issue is about instances relying on veth to connect to outside, and for such instances, `IgnoreVirtualInterfaces` should be set to `false` as described previously. We also have another issue caused by multiple networking interfaces sharing the same IP in #11557, this one is going to be resolved by #11587 If non of the above apply to you, please file a new issue with complete log and environment info so we can look it. Closing as the original issue is resolved.
Author
Owner

@iamLazyCode commented on GitHub (May 13, 2024):

i am on ubuntu server please can someone tell the fix what to do ?

@iamLazyCode commented on GitHub (May 13, 2024): i am on ubuntu server please can someone tell the fix what to do ?
Author
Owner

@HoloByteus commented on GitHub (May 15, 2024):

So glad I found this <IgnoreVirtualInterfaces>false</IgnoreVirtualInterfaces>. Bout to go insane trying to figure out why I couldn't browse to jellyfin on my Hyper-V server, nothing made sense.

@HoloByteus commented on GitHub (May 15, 2024): So glad I found this `<IgnoreVirtualInterfaces>false</IgnoreVirtualInterfaces>`. Bout to go insane trying to figure out why I couldn't browse to jellyfin on my Hyper-V server, nothing made sense.
Author
Owner

@patritha commented on GitHub (May 16, 2024):

im having a simmilar issue, exept i can access my webui but it spams my console with the output the op got. changing the setting previously mentioned had no effect. im on proxmox and using caddy reverse proxy btw

@patritha commented on GitHub (May 16, 2024): im having a simmilar issue, exept i can access my webui but it spams my console with the output the op got. changing the setting previously mentioned had no effect. im on proxmox and using caddy reverse proxy btw
Author
Owner

@Shadowghost commented on GitHub (May 16, 2024):

The output mentioned by OP doesn't has an impact and will be silenced in the next Bugfix release.

@Shadowghost commented on GitHub (May 16, 2024): The output mentioned by OP doesn't has an impact and will be silenced in the next Bugfix release.
Author
Owner

@realestninja commented on GitHub (Jul 19, 2024):

I'm on trueNAS, running jellyfin in a jail. any resources on this?

@realestninja commented on GitHub (Jul 19, 2024): I'm on trueNAS, running jellyfin in a jail. any resources on this?
Author
Owner

@EricSeastrand commented on GitHub (Sep 12, 2024):

In my case, I had to comment out all these sections in my network.xml before Jellyfin would actually bind to the port.

<!-- 
<LocalNetworkSubnets>
    <string>[REDACTED]/24</string>
</LocalNetworkSubnets> 
<LocalNetworkAddresses />
<KnownProxies>
    <string>npm.[REDACTED]</string>
</KnownProxies>
-->

I also had to set:

  <IgnoreVirtualInterfaces>false</IgnoreVirtualInterfaces>

More clues, to hopefully help the next person who lands here.

I am running Jellyfin using the LSIO docker image on a Debian 12 host.
This happened in the midst of updating my container to the latest Jellyfin version.
I even tried a fresh Jellyfin container, thinking "the defaults must work, right?" - but it gave me similar issues. A Jellyfin web UI appeared, but when I clicked the "Connect" button, it errored out. I'm guessing this is something with container-internal communication relying on virtual interfaces.
Pointing this out because: you may have to manually create the network.xml file. I am not sure what's in the default one, but maybe it's necessary to override something from it?

This breakage also coincided with introducing IPv6 to my network, which has "broken" a lot of things. I don't have IPv6 enabled in network.xml, but I know there was an issue (on other services) resolving the IP of my web proxy where the service gets an AAAA record by default. In my case, that AAAA record is pointing to Cloudflare because all my homelab stuff is IPv4.
There is a very good possibility that some of my issues stemmed from this quirk, as opposed to Jellyfin itself. Still "figuring out" ipv6.

@EricSeastrand commented on GitHub (Sep 12, 2024): In my case, I had to comment out all these sections in my `network.xml` before Jellyfin would actually bind to the port. ``` <!-- <LocalNetworkSubnets> <string>[REDACTED]/24</string> </LocalNetworkSubnets> <LocalNetworkAddresses /> <KnownProxies> <string>npm.[REDACTED]</string> </KnownProxies> --> ``` I also had to set: ``` <IgnoreVirtualInterfaces>false</IgnoreVirtualInterfaces> ``` More clues, to hopefully help the next person who lands here. I am running Jellyfin using the LSIO docker image on a Debian 12 host. This happened in the midst of updating my container to the latest Jellyfin version. I even tried a fresh Jellyfin container, thinking "the defaults must work, right?" - but it gave me similar issues. A Jellyfin web UI appeared, but when I clicked the "Connect" button, it errored out. I'm guessing this is something with container-internal communication relying on virtual interfaces. Pointing this out because: you may have to manually create the network.xml file. I am not sure what's in the default one, but maybe it's necessary to override something from it? This breakage also coincided with introducing IPv6 to my network, which has "broken" a lot of things. I don't have IPv6 enabled in `network.xml`, but I know there was an issue (on other services) resolving the IP of my web proxy where the service gets an `AAAA` record by default. In my case, that AAAA record is pointing to Cloudflare because all my homelab stuff is IPv4. There is a very good possibility that some of my issues stemmed from this quirk, as opposed to Jellyfin itself. Still "figuring out" ipv6.
Author
Owner

@bandit8623 commented on GitHub (Nov 9, 2025):

[2025-11-08 20:28:28.835 -06:00] [WRN] [10] Jellyfin.Networking.Manager.NetworkManager: "192.168.2.1": Only loopback "127.0.0.1" returned, using that as bind address.

server 2025 with a virtual switch . jelly installed on bare metal. v10.11.2
local clients see 127.0.0.1 as the server address... but clearly they cant connect. only ones that can connect are browsers

here is my network xml.. why does it want to use 192.168.2.1? 192.168.2.1 is my gateway

https://pastebin.com/1gs3x1ST

@bandit8623 commented on GitHub (Nov 9, 2025): [2025-11-08 20:28:28.835 -06:00] [WRN] [10] Jellyfin.Networking.Manager.NetworkManager: "192.168.2.1": Only loopback "127.0.0.1" returned, using that as bind address. server 2025 with a virtual switch . jelly installed on bare metal. v10.11.2 local clients see 127.0.0.1 as the server address... but clearly they cant connect. only ones that can connect are browsers here is my network xml.. why does it want to use 192.168.2.1? 192.168.2.1 is my gateway https://pastebin.com/1gs3x1ST
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/jellyfin#5690