Por que o processo do sistema está escutando na porta 443?

43

Estou tendo problemas ao iniciar meu servidor apache, porque a porta 443 já está em uso.

Acontece que, o processo do sistema (PID 4) usa a porta 443. Eu não tenho o IIS instalado, o services.msc mostra (predicatbly) nenhum servidor do Exchange em execução, nem o WWW-Services, nem o IIS. Eu não tenho idéia de como descobrir qual serviço usa essa porta, apenas desabilitando cada serviço um após o outro, e não tenho certeza se isso ajudaria.

Eu ficaria grato se alguém pudesse me apontar como eu posso ter minha porta SSL de volta, obrigado :)

P.S .: É claro que "basta mudar o apache para outra porta para SSL" resolveria o problema de não conseguir iniciar o apache. Mas eu ainda gostaria de saber o que é tão insistente sobre ocupar a porta 443. :)

Edit: Eu já tomou o 'caminho difícil' e serviços desativados um após o outro. Descobriu-se que o serviço "Routing and RAS" era o culpado. Obrigado a todos pela valiosa contribuição e as novas ferramentas no combate contra o "WTF meu sistema faz agora".

windows 
— Cornelius
fonte
Relacionado: superuser.com/questions/121901 Você pode usar qualquer uma das respostas dadas para ajudá-lo a determinar qual serviço está abrindo a porta 443.
— heavyd
1
Infelizmente, como não consigo (ou simplesmente estúpido) descobrir qual serviço mantém a porta exatamente aberta, não posso usar "SC Config Servicename Type = own" para um atraso do Servicename. Os vários encantamentos do Netstat me apontam no processo do Sistema, como dito, assim como o TCPView. "Stacks", como para PE, não funcionam no Win7 aparentemente e, como não vejo uma instância svchost.exe, não tenho uma coluna "Service" na guia TCP / IP. O Skype não tem culpa, nem tenho outro software VoIP ou P2P em execução. Mas a outra pergunta que você ligou foi esclarecedora para mim; obrigado.
— Cornelius
Obrigado pela informação! Para mim, foi o serviço "Roteamento e Acesso Remoto" que também ligou a porta 443.
— Codler
2
Cara, a quantidade de respostas que nem sequer tentam responder a pergunta é incrível. Assim é a quantidade de desinformação. Se o PID 4 estiver escutando, é http.sys. Sempre. Felizmente, já existe uma resposta sobre como obter uma visão .
— Daniel B

Respostas:

18

Execute o seguinte em um prompt de comando elevado: 

netstat -ab
— tonyr roth
fonte
Estou um pouco surpresa. Qualquer outra coisa mostrou apenas "o processo do sistema" como culpado. Este comando agora afirma que ele é um svchost.exe que contém essa porta. : | Como vem PE / 'outro' chamadas netstat submeteu-lo no processo do sistema? (Embora a porta ainda seja mostrada como mantida pelo PID 4 / System.) Como posso inspecionar mais? :(
— Cornelius
Não tenho certeza, mas execute PE elevado talvez!
— tonyr roth
2
Além disso, o seguinte pode fornecer mais informações sobre o processo wmic & gt; test.txt
— tonyr roth
1
Eu executei o Process Explorer como administrador - e ainda assim a porta aparece como reivindicada por "System"; realmente não muito mais intel disponível lá: | Até agora eu acho que vai ser algo muito estúpido que eu inconscientemente fiz;)
— Cornelius
4
Isso não funciona para mim, sob a linha de 0.0.0.0:443 Acabei de receber Não é possível obter informações sobre propriedade .
— MGOwen
32

Eu aposto que é o Skype, desmarque a caixa de seleção mostrada abaixo se você tiver instalado.

alt text

— Nifle
fonte
3
+1. Outros clientes de VoIP (e outros softwares como aplicativos de transferência de arquivos P2P) ouvirão nas portas 80 e 443 se não encontrarem mais nada lá, embora o Skype seja o "ofensor" mais comum. Não sei por que o Skype estaria aparecendo como um processo de propriedade do sistema.
— David Spillett
Infelizmente não é o Skype; nem outros clientes VoIP (nenhum instalado) nem P2P etc. etc. Verifiquei isso e não é apenas "um processo de propriedade do sistema", é "o processo do sistema" (PID 4)
— Cornelius
Estranhamente, eu tive o mesmo problema que o OP - 443 foi levado por svchost .. e ainda, desligar o Skype consertou isso.
— Blorgbeard
Teve esse problema. Seguiu estas instruções e descobriu que era o Skype: mydigitallife.info/…
— saturdayplace
Apenas por uma questão de clareza: se a sua porta é mantida por svchost e claramente visível no Process Explorer, não foi o mesmo problema que tive. Daí minha insistência em deixar claro que o processo com o nome "Sistema" parecia possuir o porto.
— Cornelius
12

Eu tive o problema que a porta 443 foi usada pelo "sistema" com o PID 4 na minha máquina com Windows 7. A solução para mim foi excluir uma "Conexão de entrada" (VPN) que existia na pasta de conexões de rede.

Parece que eu criei e esqueci de deletar depois de usar ...

— doener
fonte
1
Sim, teve o mesmo problema no Windows 8.1.
— Konstantin Pereiaslov
acabou de fazer isso win7. Ele parou de escutar no TCP 443, embora ainda esteja escutando na porta UDP 443, embora isso possa ser bom o suficiente.
— barlop
1
Eu tive esse problema no Windows Server 2008 R2 x64. Levei um tempo para encontrar seu post e estou surpreso com a resposta oficial para essa pergunta, já que ela não responde a pergunta. Obrigado!
— simontemplar
Ele funcionou para mim quando, em vez de excluir a "Conexão de entrada" (não me lembro como criá-lo novamente se eu precisar dele novamente) eu desmarcada [_] Allow other computers to connect to this one em Central de Rede e Compartilhamento, Configuração do Adaptador, Conexão de Entrada, Propriedades.
— Alexander Gelbukh
8

Geralmente, esse é o serviço do agente host VMWare (necessário para o host da VM para comms convidados) vmware-hostd.exe

Uma boa maneira de descobrir o que o processo svchost.exe está executando é usar o sysinternals process explorer.

— Tony
fonte
2
Se você tiver o VMware Workstation instalado, verifique em Editar - & gt; Preferências - & gt; VMs compartilhadas. Você provavelmente tem o compartilhamento de VM ativado e a porta padrão é 443. Você pode desativar o compartilhamento, alterar a porta e ativá-la de volta ou apenas desativá-la se não for necessária.
— gronostaj
@gronostaj Muito obrigado eu só gasto 3 horas tentando encontrar isto :(
— Simon Kirsten
7

Eu enfrentei problemas semelhantes com o encaminhamento de 443 solicitações para o meu servidor WAS. Com base nas recomendações deste tópico, foi isso que eu fiz

  1. do prompt cmd elevado correu netstat -a -n -o | findstr 443
  2. identificou o pid do processo escutando em 443
  3. Use o explorador de processos para identificar o processo do pid.
  4. No meu caso, a escuta da aplicação foi vmwarehostd.exe
  5. Parou o servidor da Estação de Trabalho VMWare services.msc. Reiniciado pelo servidor WAS

E todas as 443 solicitações chegaram a 443 felizes para sempre.

ps: Eu já tinha desinstalado skype que veio embutido com o meu windows 8. O serviço de roteamento e acesso remoto foi desativado na minha máquina

— praveen
fonte
2
-1 Ele era PID 4, era muito mais difícil. Você escreve "Used process explorer para identificar o processo do pid." & lt; - Seu não foi PID 4, por exemplo svchost ou algo parecido. O seu foi um exe de terceiros. Você poderia ter usado apenas o gerenciador de tarefas! Se você não está exibindo a coluna, veja a seguinte coluna, mas você teve sorte que seu PID não era PID 4. Não sei se o Process Explorer poderia ajudar, embora o gerenciador de tarefas não possa. Mas, certamente, no seu caso, o gerente de tarefas simples teria feito isso.
— barlop
6

Em primeiro lugar, vou responder a esta pergunta diretamente e quem ler isso pode ignorar todas as respostas falando sobre aplicativos de terceiros, não-Microsoft usando o processo do sistema.

  1. o Sistema processo está listado como PID 4 em todos os sistemas Windows modernos. É para o acesso ao modo kernel. Isso exclui a maioria dos produtos da Web de terceiros, como o Apache.

  2. Desde o início do WinRM (Windows Remote Management), o HTTP serviço ( % SystemRoot% \ system32 \ drivers \ http.sys ) tem sido uma parte padrão do Windows (Vista e posterior / Server 2008 e posterior). http.sys é executado sob o Sistema processo ( PID 4 ).

  3. Outros softwares desenvolvidos pela Microsoft também podem usar o% SystemRoot% \ system32 \ drivers \ http.sys sob o processo do sistema como IIS , SQL Reporting Services e Serviço de Implantação na Web da Microsoft ( http://support.microsoft.com/kb/2597817 ) ...

  4. As portas padrão do WinRM 1.0 foram:
    HTTP = 80
    HTTPS = 443
    O WinRM 2.0 e as portas padrão maiores são:
    HTTP = 5985
    HTTPS = 5986
    Verifique com os seguintes comandos:
    Winrm enumerar winrm / config / listener
    Winrm http://schemas.microsoft.com/wbem/wsman/1/config

Etapas de solução de problemas:

Obtenha o número do processo da porta que você está procurando (443 neste caso):

... de uma unidade não mapeada do Windows para evitar "Acesso negado":
netstat -aon | encontrar ": 443"
A saída deve se parecer com a seguinte para o Sistema processo:
C: & gt; netstat -ano | find ": 443"
TCP 0.0.0.0:443 0.0.0.0:0 ESCUTANDO 4
TCP [::]: 443 [::]: 0 ESCUTANDO 4
A última coluna é o PID (4).

  1. Corrida lista de tarefas Descobrir o que está sendo executado no processo não ajuda:
    lista de tarefas / SVC / FI "PID eq 4"
    lista de tarefas / m / FI "PID eq 4"

  2. Procure no registro pelo serviço HTTP: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ serviços \ HTTP \ Parameters \ UrlAclInfo
    Haverá uma lista de URLs (com os números das portas) que podem levar a que aplicativo está em execução e mantendo as portas:
    http: // +: 5985 / wsman / - & gt; WinRM
    https: // +: 5986 / wsman / - & gt; WinRM
    http: // +: 80 / Reports / - & gt; Servidor de Relatórios SQL
    http: // +: 80 / ReportServer / - & gt; Servidor de Relatórios SQL
    https: // server_fqdn: 443 / Reports / - & gt; Servidor de Relatórios SQL
    https: // server_fqdn: 443 / ReportsServer / - & gt; Servidor de Relatórios SQL
    http: // *: 2869 / - & gt; Serviço Simple Service Discovery Protocol (SSDPSRV)
    http: // *: 5357 / - & gt; Descoberta Dinâmica de Serviços da Web (WS-Discovery)
    https: // *: 5358 / - & gt; Descoberta Dinâmica de Serviços da Web (WS-Discovery)

Você pode então encontrar o serviço correspondente no sistema e pará-lo e ver que a porta desejada é liberada, confirmando com outro netstat -aon | encontrar ": 443" comando.

— Kenya Graham
fonte
Isso deve ser votado
— Florian Bidabe
Em relação ao ponto 6, como encontramos o processo de escuta dessas portas?
— galmok
4

Se for um processo iniciado por um serviço, o netstat -ab não ajudará.

Neste caso, tente netstat -ao | find /i "443" na linha de comando do administrador. Isto lhe dará uma saída como esta: 

    TCP   0.0.0.0:443   your_hostname:0   LISTENING   PID

Em seguida, digite outro prompt de comando do administrador tasklist | find /i "<PID>"

No meu caso, o PID era 2912 e meu comando era: tasklist | find /i "2912"

A saída do meu comando foi: 

    vmware-hostd.exe   2912 Services   0   39 856 K

wow, eu até esqueci que eu instalei o VMware para verificar uma funcionalidade ...

— elbedoit
fonte
1
Para mim isso foi PID 4 ... sendo System. Ainda sem pistas :)
— Wouter
PID 4 normalmente significa um serviço Windows nativo baseado em Microsoft, o que significa nível do kernel. Tente interromper os serviços um a um e verifique se isso resolveu o problema. Desative o serviço / desinstale o recurso que o @Wouter causou. Os serviços habituais são: Routing and RASqualquer coisa notando IIS ou World Wide Puplishing, Exchange Windows Sync Share, Web Deployment Agent Service, SQL Server Reporting Services, File Server Storage Reports Manager e similar.
— elbedoit
1

No meu caso foi o processo DTC (Distributed Transaction Coordinator) para usar a porta 443. Em particular, eu ativei o WS-AT no DTC e ele estava usando a porta 443.

Em geral, eu entendo que quando o processo do sistema (PID 4) usar porta 443 / https é um processo interno do Windows (no meu caso DTC, mas eu acho que pode ser também outro processo) se não é um site IIS usando.

— gurca
fonte
0

No meu caso, foi o DataManager da F5 Networks, que usa o Tomcat 6 internamente para servir suas páginas web. Eu esqueci de desinstalar esse aplicativo. Decisão de projeto ruim, se você me perguntar.

— Roman Zenka
fonte
0

para mim, após a atualização do Windows 2016, o Apache 443 não pôde iniciar com o evento normal listado. Eu encontrei o culpado para ser "Windows Sync Share" Service (SyncShareSvc). desativado e capaz de iniciar o Apache

— JEC
fonte
-1

O Wireshark irá lhe contar os detalhes. http://www.wireshark.org/ Ou monitor TCP: http://www.itsamples.com/tcp-monitor.html

Isso ajudará.

— adeelx
fonte
O tcp-monitor, infelizmente, não me ajudou em nada; quanto a wireshark - não consegui gerar / capturar pacotes direcionados na porta 443. :(
— Cornelius
1
A única opção restante é o Process Explorer (sysinternals) que mostrará os processos com portas. O Wireshark é um dos principais produtos nesta linha, mas não consigo compreender porque não funcionou para você: s (Você instalou o driver de captura WinPCAP?)
— adeelx
Resposta muito tardia, desculpe. Mas eu não consegui nada para registrar porque aparentemente não havia tráfego para farejar. Pelo menos eu presumo.
— Cornelius
-1 O Wireshark não mostrará nada que possa ajudar a identificar o que está na porta ... a menos que haja pacotes indo para a porta E, mesmo assim, você deve fornecer mais informações. que a pessoa deve então fazer o ping do IP e tentar descobrir o que é esse IP.
— barlop
-1

Se você tem algum tipo de driver Virtual Lan (como OpenVM, VMWare, etc.) - certifique-se de "liberar" a porta antes de fornecê-la a outra coisa.

Apenas uma sugestão rápida;)

— Ruslan Abuzant
fonte
-1

Descobri que usar a funcionalidade VPN no Windows 8 (provavelmente o mesmo para o Windows 7) usava a porta 443.

EDITED: Além disso, minha porta fechou novamente por PMB.exe (Pando Media Booster)

— user1788951
fonte
-1

Usando netstat -ao | find ":443", Descobri que a porta 443 está sendo usada pelo PID 4, que era o processo do sistema. Isso aconteceu comigo duas vezes no Windows Server 2012 e foi devido a um dos seguintes motivos:

  1. IIS estava em execução, listado como "serviço de publicação da World Wide Web" em serviços, que eu parei.
  2. O recurso Pastas de Trabalho está instalado, então eu o desinstalei.

Isso pode não ser uma solução para todos, mas pode ajudar alguns.

— anishpatel
fonte
Esta resposta realmente não adiciona nenhuma informação nova que ainda não esteja nas respostas enviadas por elbedoit ou tonyr
— Ramhound
Eu especificamente adicionei esta resposta porque desinstalar o recurso de pastas de trabalho funcionou para mim e, portanto, é uma solução potencial para o problema como ele escrito. Devo apresentar esta informação em um comentário em vez disso?
— anishpatel
Eu tive o mesmo problema que o indicado na pergunta, e a resposta de Tony não funcionou para mim. A resposta de elbedoit não ajuda quando você tem PID 4 (como afirmado na pergunta); você vai parar aleatoriamente / reiniciar os processos do sistema para corrigir o problema?
— anishpatel
Ainda não altera o fato de esta resposta parecer incompleta e parece repetir a mesma informação que já existe nas questões existentes.
— Ramhound
Nenhuma outra resposta menciona a desinstalação do recurso Pastas de Trabalho, que é uma solução para a pergunta. Repeti as informações da (s) outra (s) resposta (s) para ajudar outras pessoas com o mesmo problema a identificar se essa solução pode funcionar para elas (por exemplo, verifique se o PID é 4). Se o PID não for 4, esta resposta definitivamente não ajudará. Como esta resposta é mais incompleta do que as respostas de Doener ou Tonyr? Por favor, sugira como posso comunicar melhor a minha solução.
— anishpatel
-3

Eu tive o mesmo problema ao tentar instalar uma atualização do VMware. Eu segui para o Skype. O novo cliente é padronizado para 443.

— Cal
fonte
4
Isso é apenas uma repetição de uma resposta existente. Por favor, evite as respostas existentes em vez de repostar.
— Chenmunka
@Chenmunka Talvez ele não tenha lido
— FindOutIslamNow
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.