Colin Campbell
Colin Campbell

Reputation: 76

VS Code slow to open when opened from WSL2 behind a corporate proxy

I am trying out WSL2 for work and I'm behind a corporate proxy. I've configured the proxy within WSL so internet connectivity is working ok and I have set no_proxy as below

localhost,127.0.0.1,::1

When I open VS Code from wsl with the command code . it takes around a minute to open. When I check the log for VSCode starting it seems it is trying to connect to a server on WSL at this address 172.17.164.22:36869

My gut is that its something to do with the proxy but even if I add that ip address to no_proxy it behaves the same. When opening VSCode from WSL1 there it no delay. VSCode does successfully load after a minute and I can install extensions no problem, it is just the inital opening that is slow.

I have tried pinging that address from windows and WSL and neither recognize it, I tried it in a browser as suggested in the logs and it does return a guid looking string instantly

Any ideas?

[2021-03-02 11:39:09.199] Using shell environment from invoking shell: /tmp/vscode-distro-env.D9Yczp
[2021-03-02 11:39:09.392] Probing if server is already installed: C:\WINDOWS\System32\wsl.exe -d Ubuntu-20.04 -e sh -c "[ -d ~/.vscode-server/bin/622cb03f7e070a9670c94bae1a45d78d7181fbd4 ] && printf found || ([ -f /etc/alpine-release ] && printf alpine-; uname -m)"
[2021-03-02 11:39:09.573] Probing result: found
[2021-03-02 11:39:09.574] Server install found in WSL
[2021-03-02 11:39:09.575] Launching C:\WINDOWS\System32\wsl.exe -d Ubuntu-20.04 sh -c '"$VSCODE_WSL_EXT_LOCATION/scripts/wslServer.sh" 622cb03f7e070a9670c94bae1a45d78d7181fbd4 stable .vscode-server 0  '}
[2021-03-02 11:39:09.691] Setting up server environment: Looking for /home/barista/.vscode-server/server-env-setup. Not found.
[2021-03-02 11:39:09.691] WSL version: 4.19.128-microsoft-standard Ubuntu-20.04
[2021-03-02 11:39:09.691] WSL2-shell-PID: 627
[2021-03-02 11:39:09.691] Starting server: /home/barista/.vscode-server/bin/622cb03f7e070a9670c94bae1a45d78d7181fbd4/server.sh  --port=0 --use-host-proxy --without-browser-env-var --enable-remote-auto-shutdown 
[2021-03-02 11:39:09.992] 
[2021-03-02 11:39:09.992] 
[2021-03-02 11:39:09.992] *
[2021-03-02 11:39:09.992] * Visual Studio Code Server
[2021-03-02 11:39:09.992] *
[2021-03-02 11:39:09.992] * Reminder: You may only use this software with Visual Studio family products,
[2021-03-02 11:39:09.992] * as described in the license https://aka.ms/vscode-remote/license
[2021-03-02 11:39:09.992] *
[2021-03-02 11:39:09.992] 
[2021-03-02 11:39:09.992] IP Address: 172.17.164.22
[2021-03-02 11:39:09.992] Extension host agent listening on 36869
[2021-03-02 11:39:09.992] 
[2021-03-02 11:39:09.992] [11:39:09] Extension host agent started.
[2021-03-02 11:39:10.011] Pinging 172.17.164.22:36869...
[2021-03-02 11:40:25.179] 172.17.164.22:36869 no response
[2021-03-02 11:40:25.179] WSL resolver response: ::1:36869
[2021-03-02 11:40:25.179] To debug connection issues, open a local browser on http://[::1]:36869/version

Upvotes: 5

Views: 5577

Answers (2)

Yun Liao
Yun Liao

Reputation: 1

I also encountered a similar issue. My WSL Remote opens very slowly and it takes a long time for files to load. I tried disabling the network proxy, but the problem persisted. When I checked the network information in WSL, I found there was a VMware virtual network card inside. I tried uninstalling the virtual network card, and then the problem was resolved. The connection speed became very fast.

Upvotes: 0

Baza86
Baza86

Reputation: 2136

Your post got me thinking about a problem I've been having recently. In my case I found that VS Code and WSL2 would either lose connection or would just be dog slow to open, or to load extensions.

Your post prompted me to run a test with, and without my VPN connected. I found that VS Code started really slowly with my VPN connected, and was OK not on the VPN.

I then implemented the "remote.WSL.server.connectThroughLocalhost": true setting (File > Preferences > Settings and you can search from there) as mentioned in this post on Github. Thanks to David for the link to the issue in his post!

Upvotes: 4

Related Questions