IP & Network

Verifica porte TCP

Verifica disponibilità di porte TCP, singole o in batch.

Host or IP, ports Public addresses only. Up to 100 ports.

Try example.com cloudflare.com 1.1.1.1

Common ports web (80, 443, 8080, 8443) mail (25, 465, 587, 993, 995, 110, 143) remote (22, 23, 3389, 5900) database (3306, 5432, 6379, 27017, 1433)

Informazioni su questo strumento

Un controllo di porta è la domanda più semplice "il servizio è davvero in ascolto?" che si possa porre all'internet pubblico. La nostra Verifica delle porte (Port Checker) apre una vera connessione TCP dal nostro server di Francoforte verso l'host e le porte specificate, con timeout di 3 secondi per porta. Se l'handshake si completa, la porta è aperta; se l'host rifiuta attivamente, la porta è chiusa; se c'è silenzio, la porta è filtrata — di solito un firewall che scarta il pacchetto SYN senza risposta.

Si possono sondare fino a 100 porte per esecuzione — una singola porta (80), una lista separata da virgole (80,443,22) o un piccolo intervallo (20-25). Ogni risultato mostra il numero di porta, il verdetto, il tempo di dial e una stima del nome del servizio basata sulle assegnazioni IANA (22 → ssh, 5432 → postgresql, ecc.). Il verdetto si aggiorna riga per riga durante il dial — non serve aspettare la porta più lenta per conoscere quelle veloci.

Cosa puoi farci

Verificare un deploy senza accedere via SSH. Se il servizio dovrebbe stare sulla porta 5432 e il checker dice filtered, il listener non si è agganciato oppure il firewall blocca — soluzioni diverse, ma il port-check ti dice quale.
Audit dell'esposizione esterna. Eseguire il preset porte popolari contro il proprio server. Qualsiasi open non riconosciuta è un compito da fare. closed e filtered sono entrambi accettabili per l'internet pubblico.
Diagnosticare discussioni "il firewall deve essere sbagliato". filtered su tutte le porte dal nostro lato — ma raggiungibile dal vostro laptop — è prova concreta che il firewall dell'host ha una allowlist sull'IP sorgente, non un problema di porta.

Leggere il risultato

"Open" è inequivocabile: un listener TCP ci ha accettato. "Closed" significa che l'host è vivo e il kernel ha inviato un RST; la porta non è in uso. "Filtered" è il caso interessante: un firewall ha scartato il pacchetto senza risposta, il routing è rotto, o il listener è sovraccarico. La colonna del dial-time aiuta a distinguere — open e closed rispondono in millisecondi a una cifra; filtered si assesta sempre sul timeout pieno di 3 secondi. Molti servizi basati su UDP (DNS sulla 53, SNMP sulla 161) accettano anche TCP, ma se non lo fanno, aspettarsi filtered — è normale, non un bug.

Domande frequenti

Qual è la differenza tra "closed" e "filtered"?

Closed significa che il kernel dell'host ha risposto attivamente con un RST TCP — l'host è raggiungibile, non c'è nessun listener su quella porta. Filtered significa che non abbiamo ricevuto nulla entro 3 secondi — di solito un firewall che scarta il nostro SYN, occasionalmente un host sovraccarico. Entrambi sono comuni; solo "open" garantisce che un servizio reale sia in ascolto.

Perché tutto è "filtered" dal vostro server ma funziona per me?

Una allowlist sull'IP sorgente nel firewall dell'host. Il servizio funziona ed è raggiungibile dall'IP del vostro laptop, ma l'IP del nostro server di Francoforte non è nella lista. Questo è il risultato atteso per jump host, pannelli admin interni e qualsiasi servizio che non dovrebbe essere esposto all'internet pubblico — esattamente quello che configurereste deliberatamente.

Posso scansionare IP privati o la mia LAN?

No. Gli intervalli privati RFC 1918, loopback, link-local (169.254/16), CGN (100.64/10) e gli endpoint di metadata cloud sono rifiutati — stessa policy SSRF del resto dei nostri strumenti. Per scansionare la propria LAN usare nmap o uno strumento locale simile. I servizi pubblici devono sondare solo l'internet pubblico.

Quante porte posso controllare in una sola esecuzione?

Fino a 100 porte uniche per esecuzione. Un intervallo come 1-100 conta come 100; le liste vengono deduplicate prima del conteggio. Input oltre il limite restituiscono un 422 — suddividere la scansione in batch. Abbiamo scelto 100 perché il caso peggiore (tutte filtrate) impiega 100 × 3 s = 5 minuti; permettere di più legherebbe il worker oltre tempi di risposta ragionevoli.