¿Por qué el proceso 'Sistema' está escuchando en el puerto 443?

45

Tengo problemas para iniciar mi servidor Apache porque el puerto 443 ya está en uso.

Resulta que el proceso del sistema (PID 4) usa el puerto 443. No tengo IIS instalado, services.msc muestra (previsiblemente) que no se está ejecutando ningún servidor de Exchange, ni WWW-Services, ni IIS. No tengo idea de cómo averiguar qué servicio usa ese puerto, a excepción de deshabilitar cada servicio uno tras otro, y ni siquiera estoy seguro de que eso ayude.

Estaría agradecido si alguien pudiera señalarme cómo puedo recuperar mi puerto SSL, gracias :)

PD: Por supuesto, "simplemente cambiar Apache a otro puerto para SSL" resolvería el problema de no poder iniciar Apache. Pero todavía me gustaría saber qué es tan insistente sobre acaparar el puerto 443. :)

Por ahora tomé la "ruta difícil" y deshabilité los servicios uno tras otro. Resultó que el servicio "Enrutamiento y RAS" era el culpable.

Gracias a todos por el valioso aporte y las nuevas herramientas en el combate contra "¿Qué hace mi sistema ahora?".

windows 
— Cornelio
fuente
Relacionado: superuser.com/questions/121901 Puede usar cualquiera de las respuestas dadas para ayudarlo a determinar qué servicio está abriendo el puerto 443.
— heavyd
1
Desafortunadamente, como no puedo (o soy demasiado estúpido) descubrir qué servicio mantiene exactamente abierto el puerto, no puedo usar "SC Config Servicename Type = own" para un retraso de Servicename. Los diversos encantamientos de Netstat me señalan el proceso del Sistema, como se dijo, tal como lo hizo TCPView. "Pilas", en cuanto a PE, aparentemente no funcionan en Win7 y como no miro una instancia de svchost.exe, no tengo una columna de "Servicio" en la pestaña TCP / IP. Skype no tiene la culpa, ni tengo ningún otro software VoIP o P2P ejecutándose. Pero la otra pregunta que vinculaste fue esclarecedora para mí; gracias.
— Cornelius
Gracias por la info! Para mí fue el servicio "Enrutamiento y acceso remoto" el que también había vinculado el puerto 443.
— Codler 01 de
3
Hombre, la cantidad de respuestas que ni siquiera intentan responder la pregunta es increíble. También lo es la cantidad de información errónea. Si PID 4 está escuchando, lo es http.sys. Siempre. Afortunadamente, ya hay una respuesta sobre cómo obtener información .
— Daniel B

Respuestas:

18

Ejecute lo siguiente desde un símbolo del sistema elevado:

netstat -ab
— tonyr roth
fuente
Estoy un poco sorprendido Cualquier otra cosa mostró solo "el proceso del sistema" como culpable. Este comando ahora afirma que es -es- un svchost.exe que contiene este puerto. : | ¿Cómo las subsistencias de PE / 'otras' netstat lo subsumieron bajo el proceso del Sistema? (Aunque el puerto todavía se muestra como mantenido por PID 4 / System). ¿Cómo puedo inspeccionar más? :(
— Cornelius
No estoy seguro, pero ejecutar PE elevado tal vez!
— tonyr roth
2
también lo siguiente puede darle más información sobre el proceso wmic> test.txt
— tonyr roth
1
Ejecuté Process Explorer como administrador, y aún así el puerto aparece como lo afirma "Sistema"; no hay mucha más información disponible allí: | A estas alturas creo que será algo realmente estúpido que hice involuntariamente;)
— Cornelius
44
Esto no funciona para mí, debajo de la línea con 0.0.0.0:443 que acabo de obtener No puedo obtener información de propiedad .
— MGOwen
33

Apuesto a que es Skype. Desactive la casilla de verificación que se muestra a continuación si lo tiene instalado.

texto alternativo

— Nifle
fuente
3
+1. Otros clientes VoIP (y otro software como aplicaciones de transferencia de archivos P2P) escucharán en los puertos 80 y 443 si no encuentran nada más allí, aunque Skype es el "delincuente" más común. Sin embargo, no estoy seguro de por qué Skype se mostraría como un proceso propiedad del sistema.
— David Spillett
Lamentablemente no es Skype; ni otros clientes de VoIP (no hay ninguna instalada) ni P2P, etc, etc he comprobado eso y no es sólo "un sistema de proceso de propiedad", es "el proceso del sistema" (PID 4)
— Cornelio
Curiosamente, tuve el mismo problema ya que svchost ... tomó el OP - 443 y, sin embargo, al apagar Skype lo solucionó.
— Blorgbeard
Tuve este problema Seguí estas instrucciones y descubrí que era Skype: mydigitallife.info/…
— sábado del
Solo por razones de claridad: si svchost mantiene su puerto y está claramente visible en Process Explorer, no fue el mismo problema que tuve. De ahí mi insistencia en dejar en claro que el proceso con el nombre "Sistema" parecía ser el propietario del puerto.
— Cornelius
12

Tuve el problema de que el "sistema" utilizaba el puerto 443 con PID 4 en mi máquina con Windows 7. La solución para mí fue eliminar una "Conexión entrante" (VPN) que existía en la carpeta de conexiones de red.

Parece que lo creé y olvidé eliminarlo después del uso ...

— doener
fuente
1
Sí, tuve el mismo problema en Windows 8.1.
— Konstantin Pereiaslov
acabo de ganar7. Dejó de escuchar en TCP 443 aunque todavía está escuchando en el puerto UDP 443, aunque eso puede ser lo suficientemente bueno.
— barlop
1
Tuve este problema en Windows Server 2008 R2 x64. Me tomó un tiempo encontrar tu publicación y estoy sorprendido por la respuesta oficial a esta pregunta, ya que en realidad no responde la pregunta. ¡Gracias!
— simontemplar
Funcionó para mí cuando en lugar de eliminar la "Conexión entrante" (no recuerdo cómo volver a crearla si la necesito nuevamente) desactivé [_] Allow other computers to connect to this oneen Centro de redes y recursos compartidos, Configuración del adaptador, Conexión entrante, Propiedades.
— Alexander Gelbukh
11

En primer lugar, responderé esta pregunta directamente y cualquiera que lea esto puede ignorar cualquier respuesta que hable sobre aplicaciones de terceros que no sean de Microsoft que utilicen el Proceso del sistema.

  1. El proceso del sistema aparece como PID 4 en todos los sistemas Windows modernos. Es para el acceso en modo kernel. Esto descarta la mayoría de los productos web de terceros como Apache.

  2. Desde el inicio de WinRM (Windows Remote Management), el servicio HTTP ( % SystemRoot% \ system32 \ drivers \ http.sys ) ha sido una parte estándar de Windows (Vista y posterior / Server 2008 y posterior). http.sys se ejecuta bajo el proceso del Sistema ( PID 4 ).

  3. Otro software desarrollado por Microsoft también puede usar% SystemRoot% \ system32 \ drivers \ http.sys en el proceso del sistema como IIS , SQL Reporting Services y Microsoft Web Deployment Service ( http://support.microsoft.com/kb/2597817 ) ...

  4. Los puertos predeterminados de WinRM 1.0 fueron:
    HTTP = 80
    HTTPS = 443
    WinRM 2.0 y los puertos predeterminados superiores son:
    HTTP = 5985
    HTTPS = 5986
    Verifique con los siguientes comandos:
    Winrm enumere winrm / config / listener
    Winrm obtenga http://schemas.microsoft.com / wbem / wsman / 1 / config

Pasos de solución de problemas:

Obtenga el número de proceso del puerto que está buscando (443 en este caso):

... desde una unidad de Windows no asignada para evitar "Acceso denegado":
netstat -aon | La
salida de find ": 443" debería tener el siguiente aspecto para el proceso del sistema :
C:> netstat -ano | find ": 443"
TCP 0.0.0.0:443 0.0.0.0:0 ESCUCHANDO 4
TCP [::]: 443 [: :]: 0 ESCUCHANDO 4
La última columna es el PID (4).

  1. La ejecución de la lista de tareas para averiguar qué se está ejecutando en el proceso no es útil:
    lista de tareas / SVC / FI "PID eq 4"
    lista de tareas / m / FI "PID eq 4"

  2. Busque en el registro el servicio HTTP: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services \ HTTP \ Parameters \ UrlAclInfo
    Habrá una lista de URL (con los números de puerto) que puede llevarlo a qué aplicación se está ejecutando y qué puertos:
    http : // +: 5985 / wsman / -> WinRM
    https: // +: 5986 / wsman / -> WinRM
    http: // +: 80 / Reports / -> SQL Reporting Server
    http: // +: 80 / ReportServer / -> SQL Reporting Server
    https: // server_fqdn: 443 / Reports / -> SQL Reporting Server
    https: // server_fqdn: 443 / ReportsServer / -> SQL Reporting Server
    http: // *: 2869 / - -> Servicio de Protocolo simple de descubrimiento de servicios (SSDPSRV)
    http: // *: 5357 / ->Descubrimiento dinámico de servicios web (WS-Discovery)
    https: // *: 5358 / -> Descubrimiento dinámico de servicios web (WS-Discovery)

Luego puede encontrar el servicio correspondiente en el sistema y detenerlo y ver que el puerto deseado se libera al confirmar con otro netstat -aon | encontrar el comando ": 443" .

— Kenya Graham
fuente
Con respecto al punto 6, ¿cómo encontramos que el proceso escucha esos puertos?
— galmok
8

A menudo, este es el servicio de agente de host VMware (requerido para la comunicación VM-host-a-invitado) - vmware-hostd.exe.

Una buena forma de averiguar qué subproceso está ejecutando svchost.exe es utilizar el Explorador de procesos de Sysinternals .

— Tony
fuente
2
Si realmente tiene VMware Workstation instalada, verifique en Editar -> Preferencias -> VM compartidas. Probablemente tenga habilitado el uso compartido de VM y el puerto predeterminado es 443. Puede deshabilitar el uso compartido, cambiar el puerto y habilitarlo nuevamente o simplemente dejarlo deshabilitado si no lo necesita.
— gronostaj
@gronostaj Muchas gracias, solo paso 3 horas tratando de encontrar esto :(
— Simon Kirsten
7

Enfrenté problemas similares con el enrutamiento de 443 solicitudes a mi servidor WAS. Según las recomendaciones de esta pregunta, esto es lo que hice:

  1. Desde el cmd elevado se ejecutó el prompt netstat -a -n -o | findstr 443
  2. Identificó el PID del proceso escuchando en 443
  3. Utilizó Process Explorer para identificar el proceso desde el PID.
  4. En mi caso la aplicación de escucha fue vmwarehostd.exe
  5. Detuvo el servidor VMware Workstation de services.msc. Reiniciado por el servidor WAS.

Y todas las 443 solicitudes llegaron a 443 felices para siempre.

PD: ya había desinstalado skype que vino incluido con mi instalación de Windows 8. El servicio de enrutamiento y acceso remoto estaba deshabilitado en mi máquina.

— Praveen
fuente
3
-1 El suyo era PID 4 fue mucho más difícil. Escribe "Explorador de procesos utilizado para identificar el proceso desde el pid". <- El tuyo no era PID 4, por ejemplo, svchost o algo así. El tuyo era un exe de terceros. ¡Podrías haber usado el administrador de tareas! Si aún no está mostrando la columna, vea ... elija una columna Pero tuvo suerte de que su PID no fuera PID 4. No sé si el explorador de procesos podría ayudar allí, aunque el administrador de tareas no puede. Pero ciertamente en su caso el administrador de tareas simple lo habría hecho.
— barlop
5

Si es un proceso iniciado por un servicio, netstat -abno ayudará.

En este caso, intente netstat -ao | find /i "443"en una línea de comando de administrador. Esto le dará una salida como esta:

    TCP   0.0.0.0:443   your_hostname:0   LISTENING   PID

Luego escriba tasklist | find /i "<PID>"otro símbolo del sistema del administrador.

En mi caso, el PID era 2912 y mi comando era: 

tasklist | find /i "2912"

El resultado de mi comando fue:

vmware-hostd.exe   2912 Services   0   39 856 K

Wow, incluso he olvidado que instalé VMware para verificar una funcionalidad ...

— elbedoit
fuente
1
Para mí esto fue PID 4 ... siendo el Sistema. Todavía no tengo idea :)
— Wouter
PID 4 generalmente significa un servicio nativo de Windows basado en Microsoft, que significa nivel de kernel. Intente detener los servicios uno por uno y verifique si resolvió el problema. Deshabilite el servicio / desinstale la función que @Wouter causó el problema. Servicios habituales son: Routing and RAS, señalando nada IISo World Wide Puplishing, Exchange Windows Sync Share, Web Deployment Agent Service, SQL Server Reporting Services, File Server Storage Reports Managery similares.
— elbedoit
1

En mi caso, fue DataManager de F5 Networks que utiliza Tomcat 6 internamente para servir sus páginas web. Olvidé desinstalar esa aplicación. Mala decisión de diseño, si me preguntas.

— Roman Zenka
fuente
1

Utilizando netstat -ao | find ":443", descubrí que el puerto 443 está siendo utilizado por PID 4, que era el proceso del sistema. Esto me sucedió dos veces en Windows Server 2012, y se debió a uno de los siguientes motivos:

  1. IIS se estaba ejecutando, que figuraba como "Servicio de publicación World Wide Web" en Servicios, lo que detuve.
  2. La función Carpetas de trabajo instalada, así que la desinstalé.

Es posible que esto no sea una solución para todos, pero puede ayudar a algunos.

— anishpatel
fuente
Esta respuesta realmente no agrega ninguna información nueva que aún no estaba en las respuestas enviadas por elbedoit o tonyr
— Ramhound
1
Agregué específicamente esta respuesta porque la desinstalación de la función Carpetas de trabajo funcionó para mí y, por lo tanto, es una posible solución al problema tal como está escrito. ¿Debería presentar esta información en un comentario?
— anishpatel
1
Tuve el mismo problema que se indica en la pregunta, y la respuesta de tonyr no funcionó para mí. la respuesta de elbedoit no ayuda cuando tiene PID 4 (como se indica en la pregunta); ¿Vas a detener / reiniciar aleatoriamente los procesos del sistema para solucionar el problema?
— anishpatel
1
Ninguna otra respuesta menciona la desinstalación de la función Carpetas de trabajo, que es una solución a la pregunta. Repetí la información de la (s) otra (s) respuesta (s) para ayudar a otros con el mismo problema a identificar si esta solución podría funcionar para ellos (es decir, verifique que el PID sea 4). Si el PID no es 4, esta respuesta definitivamente no ayudará. ¿Cómo es esta respuesta más incompleta que las respuestas de doener o tonyr? Sugiera cómo puedo comunicar mejor mi solución.
— anishpatel
1
¡Sí! ¡También fue la función Carpetas de trabajo para mí! Muchas gracias por mencionar esto. De hecho, es una respuesta igualmente válida como mencionar Skype o cualquier otro servicio ...
— Wouter
1

En mi caso, fue el proceso DTC (Coordinador de transacciones distribuidas) utilizar el puerto 443. En particular, activé WS-AT en DTC, y estaba usando el puerto 443.

En general, entiendo que cuando el proceso del Sistema (PID 4) usa el puerto 443 / HTTPS, es un proceso interno de Windows (en mi caso DTC, pero creo que también puede ser otro proceso), si no es un sitio web de IIS usándolo

— gurca
fuente
0

Para mí, después de la actualización de Windows Server 2016, Apache 443 no pudo comenzar con el evento habitual en la lista.

Encontré que el culpable era el servicio "Windows Sync Share" (SyncShareSvc). Inhabilité y pude iniciar Apache.

— JEC
fuente
0

Descubrí que el uso de la funcionalidad VPN en Windows 8 (probablemente lo mismo para Windows 7) usaba el puerto 443.

Además, mi puerto se cerró nuevamente por PMB.exe (Pando Media Booster).

— usuario1788951
fuente
-1

Wireshark te dirá los detalles. http://www.wireshark.org/ O TCP Monitor: http://www.itsamples.com/tcp-monitor.html

Eso te ayudará.

— adeelx
fuente
tcp-monitor desafortunadamente no pudo ayudarme en absoluto; en cuanto a wireshark - No pude generar / capturar paquetes dirigidos al puerto 443. :(
— Cornelius
1
La única opción restante es Process Explorer (sysinternals), le mostrará procesos con puertos. Wireshark es uno de los mejores productos de esta línea, pero no puedo entender por qué no funcionó para usted: s (¿Instaló el controlador de captura WinPCAP?)
— adeelx
Muy tarde respuesta, lo siento. Pero no pude conseguir nada para registrar porque aparentemente no había tráfico para oler. Al menos eso supongo.
— Cornelius
-1 Wireshark no le mostrará nada que pueda ayudar a identificar lo que está en el puerto ... a menos que haya paquetes que vayan al puerto E incluso entonces, debe proporcionar más información, por ejemplo, que la persona debe hacer ping a la IP e intentar averiguar qué es esa IP.
— barlop
-1

Si tiene algún tipo de controlador de LAN virtual (como OpenVM, VMware, etc.), asegúrese de 'liberar' el puerto antes de dárselo a otra cosa ...

Solo una pista rápida;)

— Ruslan Abuzant
fuente
-2

Tuve el mismo problema al intentar instalar una actualización de VMware. Lo rastreé hasta Skype. El nuevo cliente predeterminado es 443.

— California
fuente
44
Esto es solo una repetición de una respuesta existente. Vota por favor las respuestas existentes en lugar de volver a publicar.
— Chenmunka
@Chenmunka Tal vez no lo leyó
— FindOutIslamNow
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.