> ## 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. # Bekannte WSL-Probleme > Beheben Sie bekannte Windsurf-Probleme bei der Ausführung im Windows Subsystem for Linux (WSL), einschließlich Leistungsproblemen durch Überlastung des Plan-9-(9P)-Dateisystemprotokolls und Verbindungsfehlern durch VPN- oder Zero-Trust-Netzwerksoftware. Diese Seite beschreibt bekannte Probleme bei der Verwendung von Windsurf mit Windows Subsystem for Linux (WSL) und die empfohlenen Lösungen. *** ## **Langsame Performance oder Verbindungsabbrüche (9P-Dateisystem-Sättigung)** Bei der Verwendung von Windsurf in WSL (über **Remote - WSL**) kann der Editor langsam werden, nicht mehr reagieren oder wiederholt die Verbindung zum WSL-Backend verlieren. Dies wird meist durch Erweiterungen verursacht, die intensives Überwachen und Indizieren von Dateien über das WSL-Dateisystem durchführen und dadurch das **Plan 9 (9P) Protokoll** auslasten – die Dateisystembrücke zwischen Windows und der WSL-Linux-Umgebung. Dies tritt insbesondere in großen Repositories und bei gleichzeitiger Ausführung mehrerer Language Server auf.
### **Symptome**
* Windsurf ist spürbar langsam oder reagiert verzögert, wenn es mit WSL verbunden ist * Der Editor verliert häufig die Verbindung zum WSL-Backend und versucht, diese wiederherzustellen * Verbindungsabbrüche treten sowohl während der aktiven Entwicklung (z. B. bei der Verwendung von Cascade) **als auch** auf, wenn der Editor untätig ist * Windsurf stürzt ab oder reagiert nicht mehr, sodass sowohl die IDE als auch WSL (`wsl --shutdown`) neu gestartet werden müssen * Die Speicherauslastung von WSL nimmt im Laufe der Zeit zu, selbst auf Systemen mit 32 GB+ RAM * WSL-Diagnose-Logs zeigen eine große Anzahl von `P9 Reply_Rlerror`-Ereignissen (Datei-nicht-gefunden-Fehler) * Die Performance ist normal, wenn Windsurf außerhalb von WSL verwendet wird (z. B. beim Öffnen eines lokalen Windows-Ordners) * Übliche Workarounds (Neustart von WSL, Neuinstallation von Windsurf, Erhöhen des in `.wslconfig` konfigurierten Speichers) beheben das Problem für sich genommen nicht ***
### **Grundursache**
Die Kommunikation zwischen Windows und dem WSL-Linux-Dateisystem verwendet das **Plan-9-(9P)-Protokoll**, das im Vergleich zu nativem Dateisystemzugriff nur einen begrenzten Durchsatz bietet. Wenn Erweiterungen in der WSL-Umgebung installiert sind, führen einige davon eine aggressive Dateiüberwachung und -indizierung über den gesamten Workspace hinweg durch. In großen Repositories (z. B. 250.000+ Dateien, 5+ GB) erzeugt das ein enormes Volumen an Dateisystemoperationen über die 9P-Brücke, was dazu führen kann, dass: * die Kapazität des Protokolls ausgeschöpft wird * Tausende `file-not-found`-Fehler (`Reply_Rlerror`) produziert werden * die Verbindung zwischen Windsurf und dem WSL-Backend abbricht * sich der Speicherdruck innerhalb von WSL im Laufe der Zeit erhöht Dies verstärkt sich, wenn zusätzlich mehrere Language Server laufen (z. B. Sorbet, Ruby LSP, TypeScript usw.), da sie weiteren Dateiüberwachungs-Overhead hinzufügen. Die kombinierte Dateisystemaktivität von Erweiterungen und Language Servern kann die 9P-Brücke selbst auf Systemen mit 32 GB oder mehr RAM überlasten. Ein bekanntes Beispiel ist die **Vue-(Volar)-Erweiterung**, bei der beobachtet wurde, dass sie in WSL-Umgebungen exzessive Dateiindizierung verursacht, selbst wenn der Workspace keine Vue-Dateien enthält. Dieses Problem ist im VS Code-Ökosystem dokumentiert: [microsoft/vscode-remote-release#11091](https://github.com/microsoft/vscode-remote-release/issues/11091) Dies ist besonders wahrscheinlich, wenn Sie eine umfangreiche Sammlung von Erweiterungen aus VS Code oder einem anderen Editor übernommen haben, die für Ihr aktuelles Projekt nicht benötigt werden. ***
### **Lösungen**
#### **1. Saubere Neuinstallation des Windsurf-Servers in WSL**
Löschen Sie das Windsurf-Server-Verzeichnis innerhalb von WSL, damit Windsurf es bei der nächsten Verbindung erneut installieren kann: ```shell theme={null} rm -rf ~/.windsurf-server ``` Verbinde Windsurf dann erneut mit WSL. Der Server wird automatisch neu installiert. ***
#### **2. Installierte Erweiterungen minimieren (höchste Wirkung)**
Installieren Sie nur Erweiterungen, die Sie aktiv für das Repository benötigen, in dem Sie arbeiten. * Öffnen Sie die Erweiterungen-Ansicht in Windsurf, während Sie mit WSL verbunden sind * Überprüfen Sie, welche Erweiterungen in der **WSL**-Umgebung installiert sind (nicht nur lokal) * Deaktivieren oder deinstallieren Sie Erweiterungen, die Sie nicht benötigen – insbesondere solche, die intensives File-Watching oder Indexing durchführen **Bekanntermaßen problematische Erweiterungen in WSL:** * **Vue (Volar)** – nachweislich Ursache für exzessives File-Indexing über die 9P-Bridge, selbst in Nicht-Vue-Projekten. Allein die Deinstallation dieser Erweiterung hat bei mehreren Nutzern Verbindungsabbrüche behoben. * Andere frameworkspezifische Spracherweiterungen (Angular, Svelte etc.) können sich ähnlich verhalten, wenn sie installiert, aber für den aktuellen Workspace nicht erforderlich sind. Gehen Sie **nicht** davon aus, dass Erweiterungen, die in einem lokalen (Nicht-WSL-)Setup einwandfrei funktionieren, sich in WSL genauso verhalten. Die 9P-Dateisystem-Bridge ist der Engpass – Erweiterungen, die lokal unproblematisch sind, können destabilisieren, wenn jede Dateizugriffsoperation die Protokollgrenze überschreiten muss. Die Reduzierung erweiterungsbedingter Dateisystemaktivität verringert direkt die Last auf der 9P-Bridge. ***
#### **3. WSL-Ressourcengrenzen optimieren**
Erstellen oder bearbeiten Sie die Datei `%USERPROFILE%\.wslconfig` auf Ihrem **Windows**-Host (z. B. `C:\Users\\.wslconfig`) mit Ressourcengrenzen, die zu Ihrem System passen: ``` [wsl2] memory=16GB swap=4GB processors=4 autoMemoryReclaim=gradual ``` Passen Sie die Werte abhängig von den verfügbaren Ressourcen Ihres Systems an. Nachdem Sie die Datei gespeichert haben, starten Sie WSL neu: ``` wsl --shutdown ``` Öffnen Sie dann Windsurf erneut und verbinden Sie sich wieder mit WSL. ***
### **Diagnose**
#### **WSL-Diagnose-Logs auf 9P-Fehler überprüfen**
Um zu bestätigen, dass eine 9P-Überlastung die Ursache ist, erfassen Sie WSL-Diagnose-Logs: ``` wsl --debug-shell ``` Oder ein vollständiges Diagnosepaket erstellen: ``` Invoke-WebRequest -UseBasicParsing "https://aka.ms/wsldiag" -OutFile wsldiag.ps1 .\wsldiag.ps1 ``` Suchen Sie in den 9P-/Dateisystem-Logs nach einer großen Anzahl von `Reply_Rlerror`-Ereignissen. Tausende (oder mehr) deuten in der Regel darauf hin, dass Erweiterungen oder Prozesse innerhalb von WSL übermäßig viele Dateisystemanforderungen erzeugen, mit denen die 9P-Bridge nicht Schritt halten kann. ***
### **Wann welche Maßnahme sinnvoll ist**
* **Erweiterungen minimieren**, wenn du viele Erweiterungen in WSL installiert hast, die du nicht aktiv benötigst, oder wenn du Erweiterungen aus einem anderen Editor migriert hast. (Maßnahme mit dem größten Effekt.) * **Saubere Server-Neuinstallation**, wenn der Zustand des Windsurf-Servers möglicherweise beschädigt oder veraltet ist (z. B. nach einem fehlgeschlagenen Update oder einem früheren Absturz). * **`.wslconfig` optimieren**, wenn WSL übermäßig viele Host-Ressourcen verbraucht oder wenn du bisher keine Ressourcenlimits konfiguriert hast. (Allgemeine Stabilitätsverbesserung für WSL.) Für beste Ergebnisse solltest du alle drei anwenden. Die Kombination aus sauberem Server, minimalen Erweiterungen und abgestimmten Ressourcenlimits geht sowohl die eigentliche Ursache (9P-Sättigung durch Erweiterungsaktivität) als auch begünstigende Faktoren (Ressourcenerschöpfung) an. *** ## **Verbindung zu WSL mit VPN oder Zero-Trust-Software nicht möglich** Windsurf kann sich nicht mit WSL verbinden und zeigt den Fehler `Couldn't install vscode server on remote server, install script returned non-zero exit status`, wenn VPN- oder Zero-Trust-Software (Twingate, Tailscale, Zscaler, Cloudflare WARP, GlobalProtect usw.) ausgehenden Netzwerkverkehr aus WSL blockiert. ### **Symptome** * Windsurf meldet `Error resolving authority` / `install script returned non-zero exit status` beim Verbinden mit WSL * WSL selbst funktioniert (`wsl -d Ubuntu -- echo hello` ist erfolgreich), aber `curl` läuft innerhalb von WSL in ein Timeout * Das Problem trat nach Installation oder Update von VPN- oder Zero-Trust-Software auf ### **Grundursache** WSL 2 leitet den Datenverkehr standardmäßig über ein NAT-basiertes virtuelles Netzwerk. VPN- und Zero-Trust-Software leitet den Datenverkehr aus diesem virtuellen Netzwerk häufig nicht weiter, sodass der Download des Windsurf-Servers stillschweigend fehlschlägt. ### **Lösung** #### **1. Mirrored Networking aktivieren** Bearbeiten Sie die WSL-Konfigurationsdatei, um Mirrored Networking zu aktivieren (normalerweise `C:\Users\\.wslconfig`). Fügen Sie Folgendes hinzu: ```ini theme={null} [wsl2] networkingMode=mirrored dnsTunneling=true autoProxy=true ``` Starten Sie dann WSL neu und bereinigen Sie veraltete Installationszustände: ``` wsl --shutdown wsl -d Ubuntu -- bash -c "rm -f ~/.windsurf-server/.installation_lock" ``` Öffnen Sie Windsurf erneut und verbinden Sie sich wieder mit WSL. Der Server wird automatisch installiert. > **Hinweis:** Erfordert WSL 2.0.0+. Führen Sie `wsl --version` aus, um die Version zu prüfen, und `wsl --update` zum Aktualisieren. #### **2. Alternative: VPN vorübergehend trennen** Wenn Sie `.wslconfig` nicht ändern können, trennen Sie Ihr VPN/ZTNA, lassen Sie Windsurf den Server installieren und verbinden Sie sich dann erneut. Zukünftige Windsurf-Updates benötigen erneut Netzwerkzugang aus WSL.