Dlaczego proces „System” nasłuchuje na porcie 443?

45

Mam problemy z uruchomieniem mojego serwera Apache, ponieważ port 443 jest już w użyciu.

Okazuje się, że proces systemowy (PID 4) korzysta z portu 443. Nie mam zainstalowanych usług IIS, services.msc pokazuje (przewidywalnie) brak uruchomionego serwera Exchange, ani usług WWW, ani IIS. Nie mam pojęcia, jak dowiedzieć się, która usługa korzysta z tego portu, poza tym, że po prostu wyłączam każdą usługę jedna po drugiej i nawet nie jestem pewien, czy to pomogłoby.

Byłbym wdzięczny, gdyby ktoś mógł wskazać mi, w jaki sposób mogę odzyskać mój port SSL, dziękuję :)

PS: Oczywiście „wystarczy przełączyć Apache na inny port dla SSL” rozwiązałoby problem braku możliwości uruchomienia Apache. Ale nadal chciałbym wiedzieć, co jest tak natarczywe w portowaniu 443. :)

Do tej pory wybrałem „trudną drogę” i wyłączyłem usługi jeden po drugim. Okazało się, że winowajcą była usługa „Routing and RAS”.

Dziękuję wszystkim za cenny wkład i nowe narzędzia w walce z „WTF robi teraz mój system?”.

windows Cornelius
źródło
Powiązane: superuser.com/questions/121901 Możesz użyć dowolnej z podanych odpowiedzi, aby pomóc Ci ustalić, która usługa otwiera port 443.
ciężki
1
Niestety, ponieważ nie jestem w stanie (lub po prostu zbyt głupio) dowiedzieć się, która usługa dokładnie utrzymuje port otwarty, nie mogę użyć „SC Config Servicenameame Type = own” dla opóźnienia nazwy serwera. Różne inkantacje Netstat wskazują, jak powiedziałem, proces systemowy, tak jak zrobił to TCPView. „Stosy”, podobnie jak PE, najwyraźniej nie działają na Win7, a ponieważ nie patrzę na instancję svchost.exe, nie mam kolumny „Usługa” na karcie TCP / IP. Skype nie ponosi winy ani nie ma uruchomionego innego oprogramowania VoIP lub P2P. Ale inne pytanie, które łączyłeś, było dla mnie pouczające; Dziękuję Ci.
Cornelius
Dzięki za informację! Dla mnie to usługa „Routing i dostęp zdalny” powiązała również port 443.
Codler
3
Człowieku, ilość odpowiedzi nawet nie próbujących odpowiedzieć na pytanie jest niesamowita. Tak samo ilość dezinformacji. Jeśli PID 4 nasłuchuje, to właśnie tak http.sys. Zawsze. Na szczęście istnieje już odpowiedź na pytanie, jak uzyskać wgląd .
Daniel B

Odpowiedzi:

18

Uruchom następujące polecenie z wiersza polecenia z podwyższonym poziomem uprawnień:

netstat -ab
Tonyr Roth
źródło
Jestem trochę zaskoczony. Wszystko inne pokazało tylko „proces systemowy” jako winowajcę. To polecenie twierdzi teraz, że jest to svchost.exe, który zawiera ten port. : | W jaki sposób wywołania PE / „inne” netstat zajmują je w procesie systemowym? (Chociaż port jest nadal pokazywany jako utrzymywany przez PID 4 / System.) Jak mogę dalej sprawdzać? :(
Cornelius
nie jestem pewien, ale może uruchomić PE podniesiony!
tonyr roth
2
także poniższe mogą dać ci więcej wglądu proces wmic> test.txt
tonyr roth
1
Uruchomiłem eksplorator procesów jako administrator - i wciąż pojawia się port, jak twierdzi „System”; naprawdę niewiele więcej dostępnych informacji: | Do tej pory myślę, że to będzie coś naprawdę głupiego, co nieświadomie zrobiłem;)
Cornelius
4
To nie działa dla mnie, zgodnie z wersją 0.0.0.0:443 Po prostu otrzymuję Nie mogę uzyskać informacji o własności .
MGOwen
33

Założę się, że to Skype. Odznacz pole wyboru pokazane poniżej, jeśli masz zainstalowane.

Tekst alternatywny

Nifle
źródło
3
+1. Inni klienci VoIP (i inne oprogramowanie, takie jak aplikacje do przesyłania plików P2P) będą nasłuchiwać na portach 80 i 443, jeśli nie znajdą tam nic innego, chociaż Skype jest najczęściej „przestępcą”. Nie jestem jednak pewien, dlaczego Skype miałby pojawiać się jako proces będący własnością systemu.
David Spillett
Niestety nie jest to Skype; ani inni klienci VoIP (nie zainstalowani) ani P2P itp. Sprawdziłem to i nie jest to tylko „proces systemowy”, to „proces systemowy” (PID 4)
Cornelius
Dziwnie, miałem ten sam problem, co svchost wziął OP - 443, a jednak wyłączenie Skype naprawiło to.
Blorgbeard
Miałem ten problem. Postępowałem
sobota
Dla jasności: jeśli twój port jest utrzymywany przez svchost i wyraźnie widoczny w Process Explorer, nie był to ten sam problem, który miałem. Stąd mój nacisk na wyjaśnienie, że proces o nazwie „System” wydaje się być właścicielem portu.
Cornelius
12

Miałem problem, że port 443 był używany przez „system” z PID 4 na moim komputerze z systemem Windows 7. Rozwiązaniem było dla mnie usunięcie „połączenia przychodzącego” (VPN), które istniało w folderze połączeń sieciowych.

Wygląda na to, że go utworzyłem i zapomniałem go usunąć po użyciu ...

doener
źródło
1
Tak, miał ten sam problem w systemie Windows 8.1.
Konstantin Pereiasłow
właśnie zrobiłem to win7. Przestał nasłuchiwać na TCP 443, chociaż nadal nasłuchuje na porcie UDP 443, choć może to być wystarczająco dobre.
barlop
1
Miałem ten problem na Windows Server 2008 R2 x64. Zajęło mi trochę czasu, aby znaleźć twój post i jestem zaskoczony oficjalną odpowiedzią na to pytanie, ponieważ tak naprawdę wcale nie odpowiada na pytanie. Dziękuję Ci!
simontemplar
Działa to dla mnie, gdy zamiast usuwania „Połączenia przychodzącego” (nie pamiętam, jak utworzyć go ponownie, jeśli będę go potrzebować) odznaczam [_] Allow other computers to connect to this onew Centrum sieci i udostępniania, Konfiguracja karty, Połączenie przychodzące, Właściwości.
Alexander Gelbukh
11

Po pierwsze, odpowiem bezpośrednio na to pytanie i każdy, kto to przeczyta, może zignorować wszelkie odpowiedzi na temat aplikacji innych firm niż Microsoft korzystających z Procesu systemowego.

  1. Proces systemowy jest wymieniony jako PID 4 w każdym współczesnym systemie Windows. Służy do dostępu w trybie jądra. Wyklucza to większość produktów internetowych innych firm, takich jak Apache.

  2. Od momentu uruchomienia WinRM (Windows Remote Management) usługa HTTP ( % SystemRoot% \ system32 \ drivers \ http.sys ) jest standardową częścią systemu Windows (Vista i nowsze wersje / Server 2008 i nowsze wersje). http.sys działa w procesie systemowym ( PID 4 ).

  3. Inne oprogramowanie opracowane przez Microsoft może również korzystać z% SystemRoot% \ system32 \ drivers \ http.sys w procesie systemowym, takich jak IIS , SQL Reporting Services i Microsoft Web Deployment Service ( http://support.microsoft.com/kb/2597817 ) ...

  4. Domyślnymi portami WinRM 1.0 były:
    HTTP = 80
    HTTPS = 443
    Domyślnymi portami WinRM 2.0 są:
    HTTP = 5985
    HTTPS = 5986
    Sprawdź za pomocą następujących poleceń:
    Winrm wylicz winrm / config / listener
    Winrm get http://schemas.microsoft.com / wbem / wsman / 1 / config

Kroki rozwiązywania problemów:

Uzyskaj numer procesowy portu, którego szukasz (w tym przypadku 443):

... z
niemapowanego dysku systemu Windows, aby uniknąć „Odmowa dostępu”: netstat -aon | find ": 443" Dane
wyjściowe powinny wyglądać następująco dla procesu systemowego :
C:> netstat -ano | find ": 443"
TCP 0.0.0.0:443 0.0.0.0:0 LISTENING 4
TCP [::]: 443 [: :]: 0 LISTENING 4
Ostatnia kolumna to PID (4).

  1. Uruchamianie tasklist aby dowiedzieć się, co działa w procesie udowadnia nieprzydatny:
    tasklist / SVC / FI "PID eq 4"
    tasklist / m / FI "PID eq 4"

  2. Poszukaj w rejestrze usługi HTTP: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services \ HTTP \ Parameters \ UrlAclInfo
    Pojawi się lista adresów URL (z numerami portów), które mogą doprowadzić cię do tego, która aplikacja jest uruchomiona i która zawiera porty:
    http : // +: 5985 / wsman / -> WinRM
    https: // +: 5986 / wsman / -> WinRM
    http: // +: 80 / Reports / -> SQL Reporting Server
    http: // +: 80 / ReportServer / -> Serwer raportowania SQL
    https: // serwer_fqdn: 443 / Raporty / -> Serwer raportowania SQL
    https: // serwer_fqdn: 443 / ReportsServer / -> Serwer raportowania SQL
    http: // *: 2869 / - -> Usługa Simple Service Discovery Protocol (SSDPSRV)
    http: // *: 5357 / ->Web Services Dynamic Discovery (WS-Discovery)
    https: // *: 5358 / -> Web Services Dynamic Discovery (WS-Discovery)

Następnie możesz znaleźć odpowiednią usługę w systemie i zatrzymać ją i sprawdzić, czy żądany port został zwolniony, potwierdzając za pomocą innej komendy netstat -aon | znajdź polecenie „: 443” .

Kenia Graham
źródło
W odniesieniu do punktu 6, jak znaleźć proces nasłuchujący dla tych portów?
galmok
8

Często jest to usługa agenta hosta VMware (wymagana do komunikacji VM-host-gość) vmware-hostd.exe.

Dobrym sposobem, aby dowiedzieć się, który proces podrzędny jest uruchomiony svchost.exe, jest skorzystanie z Eksploratora procesów Sysinternals .

Tony
źródło
2
Jeśli rzeczywiście masz zainstalowaną VMware Workstation, sprawdź w Edycja -> Preferencje -> Udostępnione maszyny wirtualne. Prawdopodobnie masz włączone udostępnianie maszyn wirtualnych, a domyślnym portem jest 443. Możesz wyłączyć udostępnianie, zmienić port i włączyć go z powrotem lub po prostu pozostawić wyłączone, jeśli nie jest potrzebne.
gronostaj
@gronostaj Dziękuję bardzo, spędziłem 3 godziny próbując znaleźć to :(
Simon Kirsten
7

Miałem podobne problemy z routowaniem 443 żądań do mojego serwera WAS. W oparciu o zalecenia zawarte w tym pytaniu zrobiłem to:

  1. Z podwyższonego polecenia cmd uruchomiono netstat -a -n -o | findstr 443
  2. Zidentyfikowano PID procesu nasłuchującego na 443
  3. Wykorzystano Process Explorer do identyfikacji procesu na podstawie PID.
  4. W moim przypadku słuchanie aplikacji było vmwarehostd.exe
  5. Zatrzymano serwer VMware Workstation od services.msc. Zrestartowany przez serwer WAS.

Wszystkie 443 prośby przyszły do ​​443 szczęśliwie.

PS: Już odinstalowałem Skype, który został wbudowany w moją instalację Windows 8. Usługa routingu i dostępu zdalnego została wyłączona na moim komputerze.

praveen
źródło
3
-1 Miał PID 4, było o wiele trudniej. Piszesz „Używany eksplorator procesów do identyfikacji procesu na podstawie pid”. <- Twój nie był PID 4 np. Svchost lub coś takiego. Twój był exe trzeciej strony. Mogłeś po prostu użyć menedżera zadań! Jeśli jeszcze nie wyświetlasz kolumny, zobacz widok. Wybierz kolumnę. Ale miałeś szczęście, że Twój PID nie był PID 4. Nie wiem, czy eksplorator procesów mógłby w tym pomóc, chociaż menedżer zadań nie. Ale z pewnością w twoim przypadku zrobiłby to prosty menedżer zadań.
barlop
5

Jeśli jest to proces rozpoczęty przez usługę, netstat -abnie pomoże.

W takim przypadku spróbuj netstat -ao | find /i "443"użyć wiersza polecenia administratora. To da ci takie wyjście:

    TCP   0.0.0.0:443   your_hostname:0   LISTENING   PID

Następnie wpisz tasklist | find /i "<PID>"inny wiersz polecenia administratora.

W moim przypadku PID wynosił 2912, a moim poleceniem było: 

tasklist | find /i "2912"

Dane wyjściowe mojego polecenia to:

vmware-hostd.exe   2912 Services   0   39 856 K

Wow, nawet zapomniałem, że zainstalowałem VMware, aby sprawdzić funkcjonalność ...

elbedoit
źródło
1
Dla mnie był to PID 4 ... będący Systemem. Nadal nie mam pojęcia :)
Wouter
PID 4 zwykle oznacza natywną usługę Windows opartą na Microsoft, co oznacza poziom jądra. Spróbuj zatrzymać usługi jeden po drugim i sprawdź, czy to rozwiązało problem. Wyłącz usługę / odinstaluj funkcję, która spowodowała problem @Wouter. Usługi zwykłe są: Routing and RAS, cokolwiek zauważyć, IISlub World Wide Puplishing, Exchange Windows Sync Share, Web Deployment Agent Service, SQL Server Reporting Services, File Server Storage Reports Manageri podobne.
elbedoit
1

W moim przypadku to DataManager z F5 Networks, który używa Tomcat 6 wewnętrznie do obsługi swoich stron internetowych. Zapomniałem odinstalować tę aplikację. Zła decyzja projektowa, jeśli mnie o to poprosisz.

Roman Zenka
źródło
1

Za pomocą netstat -ao | find ":443"dowiedziałem się, że port 443 jest używany przez PID 4, który był procesem systemowym. Zdarzyło mi się to dwukrotnie w systemie Windows Server 2012 i wynikało to z jednego z następujących powodów:

  1. Działały usługi IIS, wymienione w usłudze jako „Usługa publikowania w sieci WWW”, które zatrzymałem.
  2. Zainstalowana funkcja folderów roboczych, więc ją odinstalowałem.

To może nie być rozwiązanie dla wszystkich, ale może pomóc niektórym.

anishpatel
źródło
Ta odpowiedź tak naprawdę nie dodaje żadnych nowych informacji, których nie ma jeszcze w odpowiedziach przesłanych przez elbedoit lub tonyr
Ramhound
1
W szczególności dodałem tę odpowiedź, ponieważ odinstalowanie funkcji folderów roboczych zadziałało dla mnie, a zatem jest to potencjalne rozwiązanie problemu w takiej formie, w jakiej została napisana. Czy zamiast tego powinienem przedstawić te informacje w komentarzu?
anishpatel
1
Miałem ten sam problem, co stwierdzony w pytaniu, i odpowiedź tonyra nie działała dla mnie. Odpowiedź elbedoit nie pomaga, gdy masz PID 4 (jak podano w pytaniu); czy zamierzasz losowo zatrzymać / ponownie uruchomić procesy systemowe, aby rozwiązać problem?
anishpatel
1
Żadna inna odpowiedź nie wspomina o odinstalowaniu funkcji folderów roboczych, która jest rozwiązaniem tego pytania. Powtórzyłem informacje z innych odpowiedzi, aby pomóc innym z tym samym problemem ustalić, czy to rozwiązanie może dla nich zadziałać (tj. Sprawdź, czy PID wynosi 4). Jeśli PID nie jest 4, ta odpowiedź na pewno nie pomoże. W jaki sposób ta odpowiedź jest bardziej niekompletna niż odpowiedź doenera lub tonyra? Proszę zasugerować, w jaki sposób mogę lepiej komunikować moje rozwiązanie.
anishpatel
1
Tak! To była także funkcja folderów roboczych! Wielkie dzięki za wspomnienie o tym. Jest to rzeczywiście równie ważna odpowiedź, jak wzmianka o Skype lub innej usłudze ...
Wouter
1

W moim przypadku korzystaniem z portu 443 był proces DTC (Distributed Transaction Coordinator). W szczególności aktywowałem WS-AT w DTC i korzystał on z portu 443.

Ogólnie rozumiem, że gdy proces systemowy (PID 4) korzysta z portu 443 / HTTPS, jest to wewnętrzny proces systemu Windows (w moim przypadku DTC, ale myślę, że może to być również inny proces), jeśli nie jest to strona internetowa IIS Użyj tego.

gurca
źródło
0

Dla mnie po aktualizacji systemu Windows Server 2016 serwer Apache 443 nie mógł rozpocząć się od zwykłego zdarzenia wymienionego na liście.

Uważam, że winowajcą jest usługa „Windows Sync Share” (SyncShareSvc). Wyłączyłem i mogłem uruchomić Apache.

JE C
źródło
0

Odkryłem, że korzystanie z funkcji VPN w Windows 8 (prawdopodobnie tak samo w Windows 7) używa portu 443.

Dodatkowo mój port został ponownie zamknięty przez PMB.exe (Pando Media Booster).

użytkownik1788951
źródło
-1

Wireshark powie ci szczegóły. http://www.wireshark.org/ Lub Monitor TCP: http://www.itsamples.com/tcp-monitor.html

To pomoże.

adeelx
źródło
monitor tcp niestety nie mógł mi w ogóle pomóc; co do wireshark - nie byłem w stanie wygenerować / przechwycić pakietów skierowanych do portu 443. :(
Cornelius
1
Jedyną pozostałą opcją jest Process Explorer (sysinternals), który pokaże ci procesy z portami. Wireshark jest jednym z najlepszych produktów w tej linii, ale nie mogę zrozumieć, dlaczego to nie zadziałało: s (Czy zainstalowałeś sterownik przechwytywania WinPCAP?)
adeelx
Bardzo późna odpowiedź, przepraszam. Ale nie mogłem dostać niczego do zarejestrowania, ponieważ podobno po prostu nie było ruchu do wąchania. Przynajmniej tak przypuszczam.
Cornelius
-1 Wireshark nie pokaże ci niczego, co mogłoby pomóc zidentyfikować to, co znajduje się na porcie. Chyba że do portu docierają pakiety. Nawet wtedy powinieneś podać więcej informacji, np. Że osoba powinna pingować adres IP i spróbować się dowiedzieć co to jest IP.
barlop
-1

Jeśli masz jakiś sterownik wirtualnej sieci LAN (taki jak OpenVM, VMware itp.) - upewnij się, że port został zwolniony przed przekazaniem go do czegoś innego ...

Krótka wskazówka boczna;)

Ruslan Abuzant
źródło
-2

Miałem te same problemy podczas próby zainstalowania aktualizacji VMware. Wyśledziłem to na Skype. Domyślnie nowy klient to 443.

Cal
źródło
4
To tylko powtórzenie istniejącej odpowiedzi. Prosimy o głosowanie na istniejące odpowiedzi, a nie ponowne publikowanie.
Chenmunka,
@Chenmunka Może nie przeczytał
FindOutIslamNow