Zum Hauptinhalt springen
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 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: 
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\<YourUser>\.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\<YourUser>\.wslconfig). Fügen Sie Folgendes hinzu: 
[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.