Welches Programm belegt welchen Port? Windows-Anleitung

Welches Windows Programm belegt welchen Port? Diese Frage taucht spätestens dann auf, wenn ein Webserver, eine lokale Anwendung oder ein Spieleserver nicht startet. Häufig meldet das Programm lediglich, dass der gewünschte Port bereits verwendet wird. Wer dahintersteckt, bleibt zunächst unklar.

Unter Windows 11 und Windows 10 findest Du den verantwortlichen Prozess über die lokale Portnummer und seine Prozess-ID, kurz PID. Dafür reichen die integrierten Werkzeuge netstat und PowerShell. Anschließend kannst Du entscheiden, ob Du die vorhandene Anwendung schließt, einen Dienst überprüfst oder einen anderen Port einstellst.

Was bedeutet es, wenn ein Programm einen Port belegt?

Ein Netzwerkport ist eine nummerierte Schnittstelle für die Kommunikation von Anwendungen. Zusammen mit der IP-Adresse und dem Transportprotokoll kennzeichnet er einen Netzwerkendpunkt. Gemeint sind hier TCP- und UDP-Ports, nicht die USB-Anschlüsse Deines PCs.

Ein Programm belegt einen lokalen Port, wenn es einen entsprechenden Netzwerkendpunkt bindet. Ein Server wartet dort beispielsweise auf eingehende Verbindungen. Auch Anwendungen, die selbst Verbindungen aufbauen, benötigen lokale Ports. Deshalb bedeutet ein Eintrag in der Portübersicht nicht automatisch, dass ein Server auf Deinem Computer läuft.

Für die Zuordnung sind drei Angaben entscheidend: die lokale IP-Adresse mit der Portnummer, das Protokoll TCP oder UDP und die PID des zugehörigen Prozesses. Die Grundlagen erklärt Dir auch unser Beitrag über die Funktion und Bedeutung von Portnummern unter Windows.

Lokaler Port und entfernter Port sind nicht dasselbe

Wenn Dein Browser eine HTTPS-Verbindung zu einem Server aufbaut, steht auf der entfernten Seite häufig Port 443. Lokal verwendet der Browser normalerweise eine andere, vorübergehend zugewiesene Portnummer. Der Browser betreibt deshalb nicht automatisch einen eigenen HTTPS-Server auf Deinem PC.

Suchst Du den Verursacher eines lokalen Portkonflikts, untersuche immer die lokale Adresse. Mehr zum typischen HTTPS-Port findest Du im Beitrag über Port 443 und seine Verwendung.

Vorbereitung: Portnummer prüfen und Administratorrechte nutzen

Notiere zuerst die Portnummer aus der Fehlermeldung. Prüfe außerdem, ob die Anwendung TCP oder UDP verwendet und ob sie an eine bestimmte IP-Adresse gebunden werden soll. Diese Angaben findest Du häufig in ihren Netzwerkeinstellungen oder im Fehlerprotokoll.

Öffne die Eingabeaufforderung oder PowerShell möglichst als Administrator. Manche Portinformationen sind auch ohne erhöhte Rechte sichtbar. Bei Programmpfaden, fremden Prozessen und Systemdiensten können die Informationen jedoch eingeschränkt sein.

In dieser Anleitung steht Port 8080 beispielhaft für den gesuchten Port. Die PID 1234 ist ebenfalls nur ein Beispiel. Ersetze beide Zahlen durch die Werte auf Deinem PC. Die folgenden Diagnosebefehle lesen Informationen aus und verändern zunächst keine Einstellungen.

Mit CMD abfragen, welches Programm einen Port belegt

Schritt 1: Eingabeaufforderung als Administrator starten

Öffne das Startmenü und suche nach cmd. Starte die Eingabeaufforderung as Administrator und bestätige die Sicherheitsabfrage. Verwende für die folgenden Befehle dieses Fenster.

Schritt 2: Netzwerkverbindungen und Ports anzeigen

Gib diesen Befehl ein und bestätige mit Enter:

netstat -ano

Der Parameter -a berücksichtigt aktive TCP-Verbindungen sowie TCP-Listener und UDP-Endpunkte. Mit -n erscheinen Adressen und Ports numerisch. -o ergänzt die zugehörige Prozess-ID. Weitere Optionen erläutert unsere Anleitung zu netstat und seinen Parametern.

Eine gekürzte Beispielausgabe für einen TCP-Listener sieht so aus:

Proto  Lokale Adresse   Remoteadresse   Status      PID
TCP    0.0.0.0:8080     0.0.0.0:0       ABHÖREN     1234

Hier ist der lokale TCP-Port 8080 an den Prozess mit der PID 1234 gebunden. Je nach Sprache der Windows-Ausgabe kann statt ABHÖREN auch LISTENING erscheinen.

Schritt 3: Die gesuchte Portnummer filtern

Bei vielen Einträgen grenzt Du die Ausgabe folgendermaßen ein:

netstat -ano | findstr /C:":8080 "

Das Leerzeichen hinter der Portnummer innerhalb der Anführungszeichen gehört zum Suchtext. So wird die vollständige Portnummer abgeglichen. Bei einer Suche nach Port 80 verhindert das abschließende Leerzeichen beispielsweise zusätzliche Treffer auf Port 8080.

Wichtig: findstr durchsucht die gesamte Zeile, also auch die Remoteadresse. Kontrolliere deshalb trotz Filter die Spalte Lokale Adresse. Eine ausschließlich auf den lokalen Port begrenzte Abfrage findest Du weiter unten bei PowerShell.

Schritt 4: Den Programmnamen zur PID ermitteln

Übernimm die PID aus der letzten Spalte und frage den Prozess ab:

tasklist /FI "PID eq 1234"

In der Ausgabe steht der Name der ausführbaren Datei. Für weitere Details öffnest Du mit Strg + Umschalt + Esc den Task-Manager und wechselst zu Details. Suche dort dieselbe PID. Über das Kontextmenü kannst Du, soweit zugänglich, den Dateipfad öffnen oder die Eigenschaften der Datei prüfen. Weitere Startmöglichkeiten zeigt unsere Anleitung zum Aufrufen des Task-Managers unter Windows 11.

Die PID identifiziert eine laufende Prozessinstanz, nicht dauerhaft eine bestimmte Anwendung. Nach einem Neustart des Programms kann sie anders lauten. Kontrolliere die Zuordnung deshalb erneut, bevor Du später einen Prozess beendest.

Optional: Programmnamen direkt mit netstat anzeigen

Mit einer zusätzlichen Option kann netstat auch die beteiligten ausführbaren Dateien ausgeben:

netstat -abno

Diese Abfrage benötigt ausreichende Rechte und kann länger dauern. Der Programmname steht häufig in einer eigenen Zeile. Filterst Du die Ausgabe sofort nach einer Portnummer, kann genau diese Namenszeile verschwinden. Für eine gezielte Suche ist die Zuordnung über PID und tasklist deshalb oft übersichtlicher.

Portstatus und IP-Adressen richtig lesen

Eine gefundene Portnummer allein reicht noch nicht aus, um die Situation zu beurteilen. Diese Angaben helfen Dir bei der Einordnung:

Angabe	Bedeutung für die Fehlersuche
ABHÖREN oder LISTENING	Ein TCP-Endpunkt wartet auf eingehende Verbindungen. PowerShell bezeichnet diesen Zustand als Listen.
ESTABLISHED	Eine TCP-Verbindung besteht bereits. Das ist nicht gleichbedeutend mit einem wartenden Server.
TIME_WAIT	Windows hält nach dem Verbindungsabbau vorübergehend TCP-Zustandsinformationen vor. Der Eintrag weist nicht automatisch auf einen noch laufenden, zu beendenden Prozess hin.
127.0.0.1 oder ::1	Der Endpunkt ist an eine lokale Loopback-Adresse gebunden. Diese Adresse ist für Zugriffe auf demselben Rechner vorgesehen.
0.0.0.0	Der Endpunkt ist nicht auf eine einzelne lokale IPv4-Adresse beschränkt.
[::]	Der Endpunkt nutzt die IPv6-Wildcard-Adresse. Ob dabei auch IPv4-Verbindungen angenommen werden, hängt von der Socket-Konfiguration ab.

UDP ist verbindungslos. Dort gibt es keinen TCP-Verbindungsstatus wie LISTENING oder ESTABLISHED. Ein UDP-Endpunkt kann trotzdem an eine lokale Portnummer gebunden sein.

Mit PowerShell lokale Ports und Programme gezielt anzeigen

PowerShell ist besonders praktisch, wenn Du nicht in einer Textausgabe suchen möchtest. Die Netzwerkdaten liegen als Objekte vor. Dadurch kannst Du gezielt nach lokalem Port, Zustand oder Prozess-ID auswählen.

Einen bestimmten TCP-Port prüfen

Starte Windows PowerShell als Administrator und führe diese Abfrage aus:

Get-NetTCPConnection -LocalPort 8080 |
    Select-Object LocalAddress, LocalPort, State, OwningProcess

Anders als eine Textsuche berücksichtigt -LocalPort ausschließlich die lokale Portnummer. In OwningProcess steht die PID. Mehrere Zeilen können unterschiedliche Adressen oder Verbindungen desselben Ports zeigen.

Den zugehörigen Prozess und, soweit zugänglich, seinen Dateipfad fragst Du anschließend so ab:

Get-Process -Id 1234 |
    Select-Object Id, ProcessName, Path

Bleibt der Pfad leer, kann das an eingeschränkten Zugriffsrechten oder einem inzwischen beendeten Prozess liegen. Weitere Möglichkeiten zur Prozessanalyse findest Du im Beitrag über PowerShell Get-Process.

Meldet die Portabfrage, dass keine passenden Objekte gefunden wurden, wurde bei dieser Abfrage kein entsprechender TCP-Eintrag gefunden. Eine Berechtigungs- oder Modulfehlermeldung ist dagegen ein technisches Problem und keine Aussage über die Portbelegung.

Alle wartenden TCP-Ports mit Programmnamen auflisten

Für einen Überblick über die TCP-Listener eignet sich diese kombinierte Abfrage:

Get-NetTCPConnection -State Listen |
    Sort-Object LocalPort |
    Select-Object LocalAddress, LocalPort, OwningProcess,
        @{Name='Programm';Expression={
            (Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).ProcessName
        }} |
    Format-Table -AutoSize

Das Ergebnis ist nach Portnummer sortiert und enthält den ermittelten Prozessnamen. Die Abfrage zeigt absichtlich nur wartende TCP-Endpunkte, nicht sämtliche bestehenden Verbindungen. Schließt sich ein Prozess zwischen Netzwerkabfrage und Namensauflösung, kann sein Name in der Ausgabe fehlen.

Ein Programm ermitteln, das einen UDP-Port belegt

Für UDP verwendest Du ein eigenes Cmdlet:

Get-NetUDPEndpoint -LocalPort 8080 |
    Select-Object LocalAddress, LocalPort, OwningProcess

Auch hier liefert OwningProcess die PID. Ordne sie anschließend wie oben mit Get-Process einem Programm zu. Ein freier TCP-Port sagt nichts darüber aus, ob dieselbe Nummer unter UDP bereits verwendet wird.

Umgekehrt suchen: Welche Ports verwendet ein bestimmter Prozess?

Kennst Du bereits die PID einer Anwendung, kannst Du ihre TCP-Verbindungen und UDP-Endpunkte direkt abfragen:

Get-NetTCPConnection -OwningProcess 1234 |
    Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, State

Get-NetUDPEndpoint -OwningProcess 1234 |
    Select-Object LocalAddress, LocalPort

Das ist hilfreich, wenn ein Programm mehrere Verbindungen aufbaut. Besteht die Anwendung aus mehreren Prozessen, musst Du deren PIDs ebenfalls berücksichtigen. Die Abfrage einer einzelnen PID erfasst nicht automatisch alle zugehörigen Unterprozesse.

Ports ohne Befehle im Ressourcenmonitor prüfen

Für eine grafische Kontrolle bietet sich der integrierte Ressourcenmonitor an:

1. Drücke Windows + R, gib resmon ein und bestätige mit Enter.
2. Wechsle zur Registerkarte Netzwerk.
3. Klappe den Bereich Überwachungsports auf.
4. Sortiere nach Port und vergleiche die Angaben zu Abbild, PID, Adresse und Protokoll.

Für bestehende TCP-Verbindungen gibt es einen eigenen Bereich. Achte darauf, dass eine eventuell gesetzte Prozessauswahl die angezeigten Einträge filtern kann. Entferne diese Auswahl, wenn Du wieder alle Prozesse untersuchen möchtest.

Als zusätzliches Werkzeug eignet sich TCPView aus der Sysinternals-Sammlung. Es zeigt TCP- und UDP-Endpunkte zusammen mit den zugehörigen Prozessen und aktualisiert die Ansicht regelmäßig. Nach dem Entpacken startest Du die passende Programmdatei und vergleichst insbesondere die Spalten für Prozess, lokalen Port und PID. Das ist bei kurzzeitig auftauchenden Verbindungen oft angenehmer als wiederholte Einzelabfragen.

Port durch svchost.exe, einen Dienst oder PID 4 belegt

Den Dienst hinter svchost.exe eingrenzen

Wird als Programm svchost.exe angezeigt, hast Du einen Hostprozess für Windows-Dienste gefunden. Welche Dienste innerhalb der betreffenden Prozessinstanz laufen, zeigt dieser Befehl:

tasklist /SVC /FI "PID eq 1234"

Werden mehrere Dienste aufgelistet, handelt es sich zunächst um mögliche Beteiligte. Die Liste beweist nicht, welcher einzelne Dienst innerhalb des gemeinsamen Prozesses den Port verwendet. Prüfe deshalb zusätzlich die Dienstfunktion und die Konfiguration der betroffenen Anwendung.

Öffne mit Windows + R und services.msc die Diensteverwaltung. Dort kannst Du den angezeigten Dienstnamen seiner ausführlicheren Beschreibung zuordnen. Beende nicht den gesamten svchost-Prozess, nur weil er in der Portübersicht erscheint.

Was tun, wenn System mit PID 4 den Port verwendet?

Bei HTTP-Ports kann der Systemprozess mit PID 4 auftauchen, weil eine Anwendung die Windows-Komponente HTTP.sys verwendet. Daraus folgt nicht automatisch, dass ein bestimmter Webserver installiert ist. Gerade bei einem Konflikt mit Port 80 lohnt sich ein genauerer Blick.

Eine detaillierte Momentaufnahme des HTTP-Dienstes erhältst Du in einer administrativen Eingabeaufforderung so:

netsh http show servicestate view=requestq verbose=yes

Vergleiche die angezeigten URLs, Anforderungswarteschlangen und Prozessangaben mit dem betroffenen Port. Damit lässt sich die verantwortliche Anwendung häufig weiter eingrenzen. Eine URL-Reservierung allein ist dagegen noch kein Beleg für einen aktuell aktiven Listener.

PID 4 darfst Du nicht als vermeintlich störende Anwendung beenden. Auch das pauschale Abschalten des HTTP-Dienstes ist keine geeignete Standardlösung, weil weitere Anwendungen davon abhängen können.

Einen belegten Port sicher freigeben

Ein Portkonflikt lässt sich häufig ohne erzwungenes Beenden lösen. Gehe in dieser Reihenfolge vor:

1. Identifiziere die Anwendung und prüfe, ob sie gerade benötigt wird.
2. Speichere offene Arbeiten und schließe das Programm über seine normale Beenden-Funktion. Einen selbst gestarteten Konsolenserver stoppst Du gegebenenfalls mit Strg + C in seinem eigenen Fenster.
3. Bei einem eindeutig zugeordneten, entbehrlichen Dienst verwendest Du dessen reguläre Stoppfunktion. Beachte mögliche abhängige Dienste und andere Benutzer.
4. Müssen beide Anwendungen laufen, ändere den konfigurierbaren Port einer Anwendung, beispielsweise von 8080 auf einen zuvor geprüften Port 8081. Passe auch die Verbindungseinstellungen ihrer Clients an.
5. Prüfe die Belegung erneut und starte anschließend die gewünschte Anwendung.

Nur für eine eindeutig identifizierte, festhängende Anwendung kommt ein erzwungenes Beenden infrage:

taskkill /PID 1234 /F

Der Parameter /F erzwingt das Beenden. Dabei können ungespeicherte Daten verloren gehen und laufende Arbeiten abbrechen. Verwende diesen Befehl nicht für unbekannte Prozesse, Systemkomponenten oder gemeinsam genutzte Dienstprozesse. Prüfe unmittelbar vorher erneut, ob die PID noch zur richtigen Anwendung gehört.

Startet das Programm sofort wieder, untersuche den Dienststart, eine Wiederherstellungsfunktion oder einen Autostarteintrag. Unsere Anleitung zu Autoruns unter Windows 11 hilft beim Einordnen automatischer Programmstarts.

Port angeblich belegt, aber kein passender Prozess sichtbar?

Eine leere Trefferliste ist keine Garantie dafür, dass eine Anwendung den Port anschließend erfolgreich verwenden kann. Zwischen Abfrage und Programmstart kann sich die Situation ändern. Außerdem gibt es gebundene TCP-Endpunkte, die noch nicht auf Verbindungen warten.

Solche gebundenen, nicht lauschenden TCP-Endpunkte berücksichtigt netstat zusätzlich mit dieser Option:

netstat -qno

Schlägt die Bindung weiterhin fehl, prüfe die genaue Fehlermeldung. Eine bereits verwendete Adresse und ein verweigerter Zugriff sind unterschiedliche Fehler. Auch ausgeschlossene Portbereiche können die Verwendung einer ansonsten unauffälligen Portnummer verhindern.

Die ausgeschlossenen TCP-Portbereiche für IPv4 und IPv6 kannst Du ohne Änderungen anzeigen:

netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=tcp

Für einen UDP-Konflikt ersetzt Du protocol=tcp durch protocol=udp. Prüfe, ob Deine Portnummer innerhalb eines angezeigten Bereichs liegt. Lösche solche Einträge nicht auf Verdacht. Wähle nach Möglichkeit zunächst einen anderen, nicht ausgeschlossenen Port und kontrolliere die Netzwerkkonfiguration der betroffenen Software.

Port belegt oder Port durch die Firewall blockiert?

Portbelegung und Erreichbarkeit sind zwei verschiedene Fragen. Ein Programm kann an einem Port auf Verbindungen warten, obwohl die Windows-Firewall eingehende Zugriffe blockiert. Umgekehrt entsteht durch eine Firewallfreigabe kein Listener, wenn dort keine Anwendung wartet.

Für einen lokalen TCP-Verbindungstest auf die IPv4-Loopback-Adresse verwendest Du:

Test-NetConnection -ComputerName 127.0.0.1 -Port 8080

Steht bei TcpTestSucceeded der Wert True, konnte eine TCP-Verbindung zu genau diesem Ziel aufgebaut werden. Der Test sagt nicht, dass der Port frei ist oder die Anwendung inhaltlich korrekt arbeitet. Er prüft außerdem keine UDP-Erreichbarkeit.

Ist die Anwendung nur an eine bestimmte Netzwerkadresse gebunden, teste diese Adresse statt 127.0.0.1. Für einen Zugriff von einem anderen PC führst Du den Test dort mit der passenden IP-Adresse des Zielrechners aus.

Untersuche anschließend gezielt die Windows-Firewall und die Einstellungen der Anwendung. Schalte die Firewall nicht pauschal ab. Eine Portweiterleitung im Router betrifft die Weitergabe eingehender Verbindungen und löst keinen lokalen Konflikt zwischen zwei Programmen.

FAQ: Häufige Fragen zu belegten Ports unter Windows

Fazit: Erst den Prozess identifizieren, dann den Portkonflikt lösen

Entscheidend ist nicht nur die Portnummer, sondern ihre Zuordnung zu einer lokalen Adresse, einem Protokoll und einer aktuellen Prozess-ID. Mit diesen Angaben findest Du den tatsächlichen verantwortlichen Prozess, statt wahllos Programme und Anwendungen zu schließen. Häufig genügt anschließend ein reguläres Beenden oder eine angepasste Portkonfiguration. Systemprozesse, Reservierungen und Firewallregeln solltest Du allerdings nur dann ändern, wenn Dir ihre Funktion und die Folgen klar sind.