Verifique as portas importantes e entenda o que cada resultado realmente comprova.
Verifique apenas sistemas públicos que sejam seus ou que você tenha autorização para testar.
Comece com uma dúvida concreta sobre seu servidor, selecione poucas portas e guarde as evidências junto com o resultado. Verificamos a partir de uma rede externa, não do seu aparelho.
Exemplo ilustrativo, não um resultado ao vivo
clocktools.app
80 · 443
Digite um domínio ou um IPv4 ou IPv6 público. A seleção Site usa 80 e 443. Caminhos e portas presentes na URL não definem o teste: use o campo Portas TCP.
Exemplo ilustrativo, não um resultado ao vivo
Clique em Verificar portas ou pressione Enter. Você pode cancelar. Selecionamos um endereço DNS público e testamos até 12 portas. Cancelar ou redefinir impede que um resultado atrasado substitua a tela.
Exemplo ilustrativo, não um resultado ao vivo
443 · Resposta HTTP
HTTP 200
Evidências detalhadas
Leia a observação antes da duração. As evidências mostram método e endereço. Copie o relatório ou baixe PNG, CSV, JSON ou texto. Compartilhar a configuração não inicia outra verificação automaticamente.
Veja a interface real do ClockTools, da escolha das portas à leitura de uma verificação concluída. Estas capturas salvas mostram nosso próprio site. Não são resultados do seu host nem uma previsão do que a próxima verificação vai mostrar.
Verifique 80 e 443 no seu domínio após mudar hospedagem ou DNS. Uma resposta HTTP pode vir de um proxy, inclusive com 403 ou 502. Nosso verificador de disponibilidade de sites analisa a página; uma conexão não garante que ela funcione.
Se o SSH precisa ser acessível publicamente, verifique 22 no seu servidor. Uma recusa não é igual a um tempo esgotado. Confira o endereço de escuta e a lista de permissões sem enfraquecer a proteção só para obter um resultado verde.
Verifique somente as portas que utiliza. Uma conexão em 3306, 5432 ou 6379 merece uma revisão das regras de acesso, não um diagnóstico automático de vulnerabilidade. Redes privadas não fazem parte deste teste.
Inclua host, portas, horário e evidências. Compare verificações do mesmo host e IP após uma mudança autorizada. Uma observação diferente é uma pista, não uma prova de que a mudança foi a causa.
Uma porta não é um buraco numerado no computador. Ela permite distinguir conversas diferentes. Um servidor pode oferecer vários serviços no mesmo endereço IP porque o sistema operacional encaminha cada conexão recebida para a aplicação que a espera. O cliente também tem seu próprio ponto de conexão. Juntos, os dois pontos distinguem uma conexão de outras conversas que acontecem ao mesmo tempo.
A especificação do TCP de setembro de 1981, RFC 793, já descrevia essa relação entre portas, sockets e processos. Serviços comuns podiam usar pontos conhecidos, enquanto outras conversas podiam descobrir seus pontos de conexão dinamicamente. Isso fazia parte do projeto do TCP, muito antes da web atual. Por isso, uma porta de destino e uma porta temporária do cliente têm papéis diferentes, mesmo que ambas apareçam como números.
Convenções compartilhadas tornaram esses números úteis entre computadores e programas diferentes. A RFC 6335, publicada em agosto de 2011, documentou os procedimentos de registro de nomes de serviços e números de portas. O registro coordena usos; não inspeciona seu servidor. Quando nosso scanner associa a porta 22 ao SSH, ele apresenta uma referência comum. Isso não identifica o programa que realmente está escutando nem comprova a segurança do acesso.
A especificação principal do TCP foi consolidada na RFC 9293 em agosto de 2022. Seus fundamentos continuam importantes por trás de proxies reversos e balanceadores de carga. Uma conexão pode alcançar a entrada do serviço enquanto a aplicação por trás dela está indisponível. Queremos ajudar você a fazer a próxima pergunta útil, sem confundir um ponto acessível com uma avaliação completa de funcionamento ou segurança.
1981
A RFC 793 explica como portas e sockets distinguem conversas entre aplicações. Um host pode manter várias conexões TCP ao mesmo tempo.
2011
A RFC 6335 define procedimentos de registro e três faixas de portas. Um nome atribuído não certifica o programa nem sua segurança.
2022
A RFC 9293 substitui a RFC 793. Estabelecer uma conexão continua sendo diferente de avaliar a aplicação ou revisar sua segurança.
Imagine um servidor que você administra, cujo serviço SSH deve aceitar conexões autorizadas pela porta TCP 22. As observações abaixo são um exemplo fictício de diagnóstico, não medições do ClockTools nem uma orientação para expor um serviço privado.
Etapa 1 · TCP 22
Uma recusa explícita indica que a tentativa foi rejeitada. Em um sistema que você administra, verifique se o serviço está ativo e escuta no endereço previsto. Uma regra de acesso também pode rejeitar conexões. O resultado sozinho não identifica qual configuração precisa ser revista.
Etapa 2 · TCP 22
Uma tentativa posterior que excede o tempo não representa necessariamente uma melhora nem comprova bloqueio por firewall. Confira o endereço público, as rotas e a política de acesso prevista. Compare a partir de uma rede autorizada e anote mudanças no IP verificado. Altere uma configuração relevante por vez.
Etapa 3 · TCP 22
Uma conexão TCP é uma conclusão mais limitada do que um login SSH bem-sucedido. Verifique a identidade do servidor, a autenticação e as permissões pelo seu processo habitual de administração. Não inclua credenciais em relatórios compartilhados. Acesso público nem sempre é o resultado desejado.
Um bom registro de antes e depois reúne host, endereço verificado, porta, horário e anotações da alteração. Nossa comparação destaca observações que mudaram, mas não determina a causa. Se o IP ou a rede de verificação for diferente, considere os registros como pontos de vista distintos, não como um experimento controlado.
O IP identifica um ponto da rede e a porta TCP indica onde a conexão deve chegar. É necessário um serviço à escuta, uma rota funcional e acesso permitido. Serviço habitual descreve uma convenção, não um software detectado. Até a porta 443 pode ser usada para outra finalidade.
O registro de serviços da IANA fornece um vocabulário compartilhado. “Conexão TCP aceita em 22” é uma observação; uma versão específica do SSH não foi identificada. Nosso scanner não faz login, não lê banners e não testa exploits.
Uma rede precisa distinguir conversas em um mesmo endereço. A RFC 6335 descreve portas de sistema 0–1023, portas de usuário 1024–49151 e portas dinâmicas ou privadas 49152–65535. Aqui aceitamos destinos de 1 a 65535, mas não 0.
Essas faixas tratam de atribuição, não de segurança. Uma porta alta não é automaticamente privada. As portas locais temporárias do navegador também são diferentes dos destinos informados aqui. Registre o transporte: TCP 53 e UDP 53 exigem testes distintos. Verificamos somente TCP.
A especificação TCP descreve três mensagens: SYN, SYN-ACK e ACK. Abrir a conexão é um primeiro passo, não uma comprovação de funcionamento da aplicação. Ainda podem existir problemas de certificado, autenticação ou componentes internos. Fechamos a conexão de teste sem usar a aplicação.
Resposta HTTP significa que um ponto web respondeu. 404 continua sendo uma resposta; 403 pode refletir uma regra de acesso e 502 um problema de gateway. Nenhum deles verifica a porta do servidor de origem. A duração da tentativa não é ping nem um teste da sua internet doméstica.
Uma aplicação local pode escutar apenas em loopback, não ter encaminhamento no roteador ou aplicar uma lista de permissões. NAT e NAT da operadora complicam conexões de entrada. Consulte Qual é meu IP? para conferir o endereço visível e nossa calculadora de sub-redes IP para entender sua rede.
Um domínio pode retornar vários IPv4 e IPv6. Para TCP, selecionamos um endereço público validado, não todos os servidores. Um proxy pode responder sem revelar a origem. O guia de estados de portas do Nmap também trata estados como observações de um teste específico. Tempo esgotado admite várias causas; guarde os horários das comparações autorizadas.
Nosso scanner valida hosts públicos e uma lista limitada de portas TCP decimais. Seleciona um endereço DNS seguro e distingue conexão, recusa explícita, tempo esgotado, verificação indisponível e resposta HTTP. Os nomes habituais dos serviços são referências, não identificação de software.
Relate uma observação contestada pela nossa página de contato com host público, portas, horário e evidências. Inclua a configuração esperada e uma comparação autorizada, nunca senhas ou dados de redes privadas. Analisamos erros reproduzíveis de classificação ou exibição, sem transformar condições variáveis em fatos permanentes.
Não. Confira se o acesso público é intencional e revise autenticação, atualizações e regras de acesso pelo seu processo de segurança. Este scanner não identifica versões nem testa exploits.
Você pode testar o endereço público e a porta de destino de um sistema que controla. Serviço, encaminhamento e firewall precisam permitir a conexão. Tempo esgotado não identifica a camada que falhou; endereços privados não são testados.
Este serviço não testa a porta 25. Indicamos a limitação em vez de declarar a porta SMTP fechada. 587, 993 e 995 podem ser relevantes para clientes de e-mail, mas não substituem um teste de entrega SMTP na 25.
Não. Testamos portas TCP em um endereço DNS público selecionado. TCP 53 não é um teste de DNS por UDP. Uma conexão não garante respostas DNS corretas, entrega de e-mails ou a saúde de todos os servidores.
Uma restrição ou um erro ambíguo não comprova recusa. Distinguimos recusa explícita, tempo esgotado e resposta HTTP. Não verificado significa que o estado TCP real permanece desconhecido.
Até cinco observações concluídas são salvas localmente neste navegador, quando possível. Limpar histórico apaga essa lista. O link contém host e portas e não inicia o teste; os relatórios incluem a observação e suas limitações.