> ## Documentation Index > Fetch the complete documentation index at: https://docs.windsurf.com/llms.txt > Use this file to discover all available pages before exploring further. # Problemas Conhecidos do WSL > Solucione problemas conhecidos do Windsurf no Windows Subsystem for Linux (WSL), incluindo problemas de desempenho por saturação do sistema de arquivos Plan 9 (9P) e falhas de conexão causadas por VPN ou software de rede zero-trust. Esta página cobre os problemas conhecidos ao usar o Windsurf com o Windows Subsystem for Linux (WSL) e suas correções recomendadas. *** ## **Desempenho lento ou desconexões (saturação do sistema de arquivos 9P)** Ao usar o Windsurf no WSL (via **Remote - WSL**), o editor pode ficar lento, parar de responder ou se desconectar repetidamente do backend do WSL. Isso normalmente é causado por extensões que fazem monitoramento e indexação de arquivos de forma agressiva sobre o sistema de arquivos do WSL, o que satura o **protocolo Plan 9 (9P)** — a ponte de sistema de arquivos entre o Windows e o ambiente Linux do WSL. Isso é mais provável em repositórios grandes e quando vários servidores de linguagem são executados simultaneamente.
### **Sintomas**
* Windsurf fica visivelmente lento ou com atraso quando conectado ao WSL * O editor se desconecta com frequência do back-end do WSL e tenta se reconectar * As desconexões ocorrem durante o desenvolvimento ativo (por exemplo, ao usar o Cascade) **e** enquanto o editor está ocioso * Windsurf trava ou fica sem resposta, exigindo reiniciar tanto o IDE quanto o WSL (`wsl --shutdown`) * O uso de memória do WSL aumenta ao longo do tempo, mesmo em sistemas com 32 GB+ de RAM * Os logs de diagnóstico do WSL mostram um grande número de eventos `P9 Reply_Rlerror` (erros de arquivo não encontrado) * O desempenho é normal ao usar o Windsurf fora do WSL (por exemplo, ao abrir uma pasta local do Windows) * Soluções paliativas comuns (reiniciar o WSL, reinstalar o Windsurf, aumentar a memória no `.wslconfig`) não resolvem o problema por si só ***
### **Causa raiz**
A comunicação entre o Windows e o sistema de arquivos Linux do WSL usa o **protocolo Plan 9 (9P)**, que tem uma taxa de transferência limitada em comparação com o acesso nativo ao sistema de arquivos. Quando extensões são instaladas no ambiente WSL, algumas realizam monitoramento e indexação de arquivos de forma agressiva em todo o workspace. Em repositórios grandes (por exemplo, 250.000+ arquivos, 5+ GB), isso gera um volume massivo de operações no sistema de arquivos através da ponte 9P, o que pode: * Saturar a capacidade do protocolo * Produzir milhares de erros de arquivo não encontrado (`Reply_Rlerror`) * Fazer com que a conexão entre o Windsurf e o backend do WSL caia * Contribuir para o aumento gradual da pressão de memória dentro do WSL ao longo do tempo Isso é agravado quando múltiplos servidores de linguagem (language servers) também estão em execução (por exemplo, Sorbet, Ruby LSP, TypeScript etc.), já que eles adicionam mais sobrecarga de monitoramento de arquivos. A atividade combinada de acesso ao sistema de arquivos das extensões e dos servidores de linguagem pode sobrecarregar a ponte 9P mesmo em sistemas com 32 GB+ de RAM. Um exemplo conhecido é a **extensão Vue (Volar)**, que já foi observada causando indexação excessiva de arquivos em ambientes WSL mesmo quando o workspace não contém arquivos Vue. Esse problema está documentado no ecossistema do VS Code: [microsoft/vscode-remote-release#11091](https://github.com/microsoft/vscode-remote-release/issues/11091) Isso é especialmente provável se você tiver migrado um grande conjunto de extensões do VS Code ou de outro editor que não são necessárias para o seu projeto atual. ***
### **Soluções**
#### **1. Reinstalação limpa do servidor do Windsurf no WSL**
Remova o diretório do servidor do Windsurf no WSL e deixe o Windsurf reinstalá-lo na próxima conexão: ```shell theme={null} rm -rf ~/.windsurf-server ``` Em seguida, conecte novamente o Windsurf ao WSL. O servidor será reinstalado automaticamente. ***
#### **2. Minimize o número de extensões instaladas (maior impacto)**
Instale apenas as extensões de que você realmente precisa para o repositório em que está trabalhando. * Abra o painel de Extensões no Windsurf enquanto estiver conectado ao WSL * Revise quais extensões estão instaladas no ambiente **WSL** (não apenas localmente) * Desative ou desinstale as extensões de que você não precisa — especialmente aquelas que fazem monitoramento intenso de arquivos ou indexação **Extensões problemáticas conhecidas no WSL:** * **Vue (Volar)** — foi confirmado que causa indexação excessiva de arquivos através da ponte 9P, mesmo em projetos que não usam Vue. Desinstalar apenas essa extensão já resolveu desconexões para vários usuários. * Outras extensões de linguagem específicas de frameworks (Angular, Svelte, etc.) podem se comportar de forma semelhante se estiverem instaladas, mas não forem necessárias para o workspace atual. **Não** presuma que extensões que funcionam bem em uma configuração local (sem WSL) se comportarão da mesma forma no WSL. A ponte de sistema de arquivos 9P é o gargalo — extensões que são inofensivas localmente podem se tornar desestabilizadoras quando cada operação de arquivo precisa atravessar o limite do protocolo. Reduzir a atividade de sistema de arquivos gerada por extensões reduz diretamente a carga na ponte 9P. ***
#### **3. Otimize os limites de recursos do WSL**
Crie ou edite o arquivo `%USERPROFILE%\.wslconfig` no seu host **Windows** (por exemplo, `C:\Users\\.wslconfig`) com limites de recursos apropriados para o seu sistema: ``` [wsl2] memory=16GB swap=4GB processors=4 autoMemoryReclaim=gradual ``` Ajuste os valores de acordo com os recursos disponíveis no seu sistema. Depois de salvar o arquivo, reinicie o WSL: ``` wsl --shutdown ``` Em seguida, reabra o Windsurf e reconecte-se ao WSL. ***
### **Diagnóstico**
#### **Verifique os logs de diagnóstico do WSL em busca de erros 9P**
Para confirmar que a causa é a saturação do 9P, colete os logs de diagnóstico do WSL: ``` wsl --debug-shell ``` Ou gere um pacote completo de diagnóstico: ``` Invoke-WebRequest -UseBasicParsing "https://aka.ms/wsldiag" -OutFile wsldiag.ps1 .\wsldiag.ps1 ``` Procure por altos volumes de eventos `Reply_Rlerror` nos logs do 9P/filesystem. Milhares (ou mais) normalmente indicam que extensões ou processos dentro do WSL estão gerando solicitações excessivas ao sistema de arquivos que a ponte 9P não consegue processar. ***
### **Quando usar cada correção**
* **Minimizar extensões** se você tiver muitas extensões instaladas no WSL que não usa ativamente ou se tiver migrado extensões de outro editor. (Mudança de maior impacto.) * **Reinstalação limpa do servidor** se o estado do servidor do Windsurf pode estar corrompido ou obsoleto (por exemplo, após uma atualização com falha ou um travamento anterior). * **Otimizar `.wslconfig`** se o WSL estiver consumindo recursos excessivos do host ou se você ainda não tiver configurado limites de recursos. (Melhora geral da estabilidade do WSL.) Para melhores resultados, aplique as três. A combinação de um servidor limpo, extensões mínimas e limites de recursos ajustados aborda tanto a causa raiz (saturação de 9P devido à atividade de extensões) quanto os fatores que contribuem (esgotamento de recursos). *** ## **Não é possível conectar ao WSL com VPN ou software zero-trust** O Windsurf não consegue se conectar ao WSL com o erro `Couldn't install vscode server on remote server, install script returned non-zero exit status` quando um VPN ou software zero-trust (Twingate, Tailscale, Zscaler, Cloudflare WARP, GlobalProtect, etc.) bloqueia o tráfego de rede de saída de dentro do WSL. ### **Sintomas** * O Windsurf exibe `Error resolving authority` / `install script returned non-zero exit status` ao conectar ao WSL * O WSL em si funciona (`wsl -d Ubuntu -- echo hello` tem sucesso), mas `curl` expira dentro do WSL * O problema começou após a instalação ou atualização de um VPN ou software zero-trust ### **Causa raiz** O WSL 2 roteia o tráfego através de uma rede virtual baseada em NAT por padrão. Softwares VPN e zero-trust frequentemente não encaminham o tráfego dessa rede virtual, fazendo com que o download do servidor do Windsurf falhe silenciosamente. ### **Solução** #### **1. Habilitar rede espelhada (mirrored networking)** Edite o arquivo de configuração do WSL para habilitar a rede espelhada (normalmente `C:\Users\\.wslconfig`). Adicione o seguinte: ```ini theme={null} [wsl2] networkingMode=mirrored dnsTunneling=true autoProxy=true ``` Em seguida, reinicie o WSL e limpe qualquer estado de instalação obsoleto: ``` wsl --shutdown wsl -d Ubuntu -- bash -c "rm -f ~/.windsurf-server/.installation_lock" ``` Reabra o Windsurf e reconecte-se ao WSL. O servidor será instalado automaticamente. > **Nota:** Requer WSL 2.0.0+. Execute `wsl --version` para verificar e `wsl --update` para atualizar se necessário. #### **2. Alternativa: desconectar temporariamente o VPN** Se você não puder alterar o `.wslconfig`, desconecte seu VPN/ZTNA, deixe o Windsurf instalar o servidor e reconecte-se. Futuras atualizações do Windsurf exigirão acesso à rede a partir do WSL novamente.