Unlike WSL1, you cannot use or localhost to connect back to Windows in WSL2. When you start WSL2, it gets its own IP address and works more like a Hyper-V virtual machine. Microsoft seems to be working on changing this behavior and planning on supporting shared loopback addresses just like WSL1 but it's not yet happened.

In order to use X410 with Linux GUI apps or desktop environments running in WSL2, you need to make the following changes:

  • Enable 'Allow Public Access' option in X410

    When you first install X410, it only allows connections from loopback addresses such as for security reasons. But WSL2 runs in a secure sandbox with its own isolate network as mentioned above. So we first need to allow connections from any device including WSL2 for X410. This can be done by enabling 'Allow Public Access' option in X410 tray-icon popup menu.

    When you enable this option for the first time, you'll see a 'Windows Security Alert' popup window for your confirmation about allowing X410 to accept connections from public network. You must allow this 'Public' access in order to have Linux GUI apps running in WSL2 communicate with X410.

    For your information, you may see a similar 'Windows Security Alert' popup window again when X410 is updated to a new version. It seems Windows Defender Firewall treats each executable version separately even though they all belong to the same Microsoft Store app. Such behavior also leaves multiple 'x410' (lower-case x) entries in Windows Defender Firewall; you can safely remove those 'x410' entries from previous versions.

    If you're concerned about security risks for allowing such public access, you can configure Windows Defender Firewall and allow connections to X410 only from WSL2. Please consult Windows Defender Firewall documentation for additional information.

  • Update DISPLAY environment variable

    WSL2 has its own IP address and doesn't yet share loopback addresses; when you're connecting to in WSL2, you're actually connecting to a WSL2 virtual machine rather than the underlying Windows. So you need to directly use the IP address assigned for Windows.

    We recommend using the internal IP address that is automatically added to '/etc/resolv.conf' file in WSL2. This address may get changed when you reboot Windows or WSL2 is restarted. So you should dynamically extract an address from that file and assign it to the DISPLAY environment variable:

    export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2; exit;}'):0.0

    Please also note that our cookbook recipes for WSL1 should also work for WSL2 just by changing the DISPLAY environment variable; instead of using 'export DISPLAY=', use the export command shown above. For example, the following shows commands for launching Xfce desktop in WSL1 (Ubuntu 18.04, Step 2):

    start /B x410.exe /desktop
    ubuntu1804.exe run "if [ -z \"$(pidof xfce4-session)\" ]; then export DISPLAY=; xfce4-session; pkill '(gpg|ssh)-agent'; fi;"

    When you're using WSL2, you just need to change the DISPLAY environment variable setting portion:

    start /B x410.exe /desktop
    ubuntu1804.exe run "if [ -z \"$(pidof xfce4-session)\" ]; then export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2; exit;}'):0.0; xfce4-session; pkill '(gpg|ssh)-agent'; fi;"

How do I check if my WSL2 is ready for X410?

As mentioned above, the current version of WSL2 runs in an isolated network. So you need to make sure any program running in WSL2 can make connections back to Windows where X410 is running on. If you can confirm one program successfully making such connections, other Linux GUI apps should also be able to make use of X410.

If you're familiar with nc (netcat) command, you can use it for testing the connections between Windows and WSL2 without actually running a Linux GUI app.

  1. Get the IP address of Windows

    You should already have set the DISPLAY environment variable as mentioned above. This variable contains the IP address that is used by Linux GUI apps for connecting back to X410 in Windows.

    echo $DISPLAY
  2. Run nc

    Let's assume the IP address revealed in Step 1 is ''. Execute the following command while X410 is running:

    nc -v 6000

    You should get the following message if X410 can be connected and ready for WSL2:

    Connection to 6000 port [tcp/x11] succeeded!

    If you're getting the following error message, there is a problem with Windows network and/or firewall settings. Please first check the allowed apps setting in Windows Defender Firewall and make sure X410 is allowed for 'Public' access. If you see multiple entries of 'x410' (lower-case x), you can remove all of them and restart X410; you'll see the alert message box mentioned above and get a chance to set the 'Public' access option again.

    nc: connect to port 6000 (tcp) failed: Connection refused

    Also, if you're using third-party security software, make sure WSL2 and X410 are not blocked or quarantined. For additional troubleshooting, check the following post for WSL from Microsoft:


Did Linux GUI apps stopped working after waking up from Windows sleep mode?

WSL2 seems to have inherited this problem from Hyper-V. You can avoid this issue in Hyper-V by using VSOCK. But, unfortunately, WSL2 doesn't yet support VSOCK or other methods that can be used for avoiding this problem. We'll update this page as soon as we find a workaround or when Microsoft fixes it! Stay tuned.

This problem seems to be fixed in the recent versions of Windows. We're not sure if it's permanently fixed or some kind of side effect. But if you're experiencing similar problems, try updating your Windows to its latest version.

Share This Story, Choose Your Platform!