How to Test IPv6 Ports: Check Whether Ports 80, 443, and 22 Are Open Online

Your server is already configured with IPv6, the domain's AAAA record resolves correctly, and pinging the IPv6 address still gets a response—yet the website won't open and SSH won't connect. When this happens, repeatedly pinging usually won't reveal the real problem. That's because being able to reach an IPv6 address doesn't mean the service ports on the server are necessarily reachable.

Ping is mainly used to determine whether the IPv6 network is basically reachable, while services like websites, SSH, and APIs ultimately depend on specific TCP ports. For example, an HTTPS website typically needs to connect to port 443, HTTP uses port 80, and SSH commonly uses port 22. If the server only allows ICMP but doesn't permit the corresponding TCP port, you may encounter the situation where "IPv6 Ping works fine, but the website fails to load."

So after confirming basic IPv6 connectivity, the next step is usually to perform an IPv6 port test. This article starts with IPv6 port testing methods, explaining in detail how to check common ports like 80, 443, and 22, how to interpret test results, and how to troubleshoot when IPv6 can be pinged but the port is unreachable.

1. Why can IPv6 be pinged but the port isn't necessarily accessible?

In IPv6 website deployment and server operations, many people encounter a strange phenomenon: running an IPv6 Ping command in the terminal clearly returns a normal latency response, but opening the website in a browser keeps showing a timeout, and even connecting via SSH in the terminal throws an error.

This situation—where "IPv6 can be pinged but the service port won't open"—is actually very common.

The root cause is that Ping and website access verification are testing two completely different layers of the network.

When we try to access a website or remote server over IPv6, the entire data transmission process actually needs to pass through the following checkpoints in order:

1. IPv6 address link reachability (basic network connectivity)

2. TCP port connection established (transport layer channel open)

3. TLS / SSH protocol handshake (encryption and authentication)

4. Application service returns response (Web / SSH service working normally)

The Ping command only verifies the first checkpoint.

Ping uses the ICMPv6 protocol, and its main job is to test whether the network path between the local device and the target IPv6 address is clear. As long as the network card is configured with an IPv6 address, the gateway is correct, and routers along the way don't block ICMP packets, Ping will return a nice latency response.

But that doesn't mean the later checkpoints are also clear.

For example, a typical HTTPS website depends on TCP port 443 at the transport layer; HTTP depends on port 80; and SSH remote management depends on port 22. If on the server side the system firewall blocks inbound traffic on TCP 443, or the web service itself isn't listening on the IPv6 address at all, you'll get a very typical failure pattern:

• IPv6 Ping test: normal response (28ms latency)

• TCP port 443 test: connection timeout

• HTTPS website access: cannot open

The reverse situation also holds true. For security reasons, many enterprise servers and data center facilities disable ICMP Echo responses entirely. In that case, pinging the server's IPv6 address will show all timeouts, but as long as the server permits the TCP port, the HTTPS website and SSH service can still be accessed normally.

Therefore, when troubleshooting issues like an IPv6 website not opening or a service connection failing, you can't use the Ping result as the sole criterion for whether a service is available. After confirming the IPv6 address is reachable, the more critical step is to conduct in-depth testing of the specific TCP service port.

2. What exactly does an IPv6 port test test?

An IPv6 port test is essentially determining: whether the testing device can establish a connection to the specified TCP port on the target server over the IPv6 network.

Two key conditions are involved here: one is that the IPv6 network itself can reach the target server; the other is that the corresponding port on the server is actually in a connectable state.

Different services require checking different ports.

What's the difference between Ping and an IPv6 port test?

When troubleshooting IPv6 issues, many people confuse Ping with TCP port detection. Although both can determine whether "the network is reachable," they test at different layers.

For example, when a website is behaving abnormally, if IPv6 Ping is normal, the next step shouldn't be to keep staring at Ping latency—you should directly test port 80 or 443. This is also why a server can be pinged yet still fail to open a website.

3. How do you test IPv6 ports?

IPv6 port testing isn't complicated. For temporary troubleshooting, you can use built-in commands on Windows or Linux. If you need to determine whether accessing the same IPv6 port differs across regions or ISPs, it's better to use an online TCPing tool.

1. Use Chahu online TCPing to test IPv6 ports

If you want to check server ports from a public network environment, you can use Chahu's TCPing:

https://www.chahu.com/tcping

Chahu's TCPing is mainly used to detect the connectivity status and connection time of a specified TCP port, and can test from nodes in different regions and ISPs. Compared to just connecting once from your own computer, this approach makes it easier to determine whether a port anomaly is a problem with the server itself or only occurs in certain network environments.

The actual testing logic isn't complicated:

Enter domain or IPv6 address
        ↓
Fill in the TCP port to test
        ↓
Start TCPing
        ↓
View connection results from different nodes
        ↓
Determine whether all failed or only some regions are abnormal

For example, to test an HTTPS website, focus on checking port 443; if SSH can't connect, check port 22.

What's really worth looking at isn't just "whether it can connect," but also whether results are consistent across different regions.

Suppose the test results look like this:

Beijing Telecom       443 normal
Shanghai Unicom       443 normal
Hangzhou Mobile       443 normal
Guangzhou Mobile      443 timeout
Shenzhen Mobile       443 timeout

In this case, you can't simply interpret it as "port 443 isn't open." If the port were truly completely closed, usually only individual routes wouldn't have problems. At this point you also need to consider IPv6 routing, ISP networks, or intermediate security policies.

2. Testing IPv6 ports on Windows

On Windows, you can directly test TCP ports using PowerShell's Test-NetConnection.

For example, to check port 443 on an IPv6 server:

Test-NetConnection -ComputerName 2001:db8:1234::10 -Port 443

After running, focus on:

TcpTestSucceeded : True

If the result is: True, it means the current computer can basically establish a connection to the target server's TCP 443 over IPv6; if it's: False, you need to continue checking port listening, firewall, security groups, and the IPv6 network path.

You can also test domains directly:

Test-NetConnection example.com -Port 443

However, on dual-stack websites, a domain may have both A and AAAA records. If the goal is specifically to troubleshoot IPv6, it's best to also confirm the address actually used for the connection, to avoid mistaking IPv4 test results for IPv6 results.

3. Testing IPv6 ports on Linux

On Linux, you can use nc.

For example, to test IPv6 port 443:

nc -6 -vz 2001:db8:1234::10 443

To test SSH:

nc -6 -vz 2001:db8:1234::10 22

Where:

-6    Force IPv6
-v    Show detailed results
-z    Only check the port, don't send service data

If testing an HTTPS website, you can further use:

curl -6 -I https://example.com

This step goes beyond simply checking whether TCP 443 can be reached—it continues to verify whether an HTTPS service in an IPv6 environment can establish a connection and return an HTTP response.

So in practice, you can troubleshoot layer by layer: IPv6 Ping → TCP 443 → TLS → HTTP Response

Once you know which layer the problem is at, the scope of investigation narrows considerably.

4. How Do You Assess IPv6 Ports 80, 443, and 22 Separately?

During actual troubleshooting, different service ports involve different access paths and areas of focus. Below we break down the specific approach and decision logic for the three most critical ports: 80, 443, and 22.

IPv6 Port 80 (HTTP Service)

Port 80 is the foundational port for traditional HTTP web services. The underlying data flow when a user accesses a service through port 80 is roughly:

User client → IPv6 transport path → TCP port 80 handshake → Web server process (e.g., Nginx/Apache) → Return HTTP response

If testing reveals that IPv6 Ping works perfectly but TCP port 80 consistently times out, there are two most common directions to investigate:

1. Missing service listener: The web service may only be bound to an IPv4 address (0.0.0.0:80) and hasn't enabled IPv6 listening;

2. Policy blocking: The cloud server platform's IPv6 inbound security group rules or the system's internal firewall (such as ip6tables, nftables) haven't allowed TCP port 80.

Note that the vast majority of websites now enforce site-wide HTTPS, typically redirecting port 80 traffic to port 443 via 301 or 302. Therefore, a successful port 80 test only means the basic HTTP path is fine—it doesn't necessarily mean port 443 is also available. The two must be verified independently.

IPv6 Port 443 (HTTPS Service)

Port 443 is the most frequently encountered and most complex area in IPv6 website troubleshooting. Compared to plain HTTP, a complete HTTPS access involves more rigorous protocol interaction:

IPv6 basic network → TCP port 443 connection → TLS/SSL encrypted handshake → Send HTTPS request → Web server processes and responds

When troubleshooting port 443, you must clearly distinguish between two very different failure scenarios:

• TCP port 443 connection failure (timeout or refused): This is a classic transport-layer and network-layer issue. Investigation priority should focus on cloud server security groups, system firewalls, CDN edge node configuration, and IPv6 routing paths.

• TCP port 443 is fine, but the browser reports an HTTPS error: If TCPing confirms that port 443 can establish a connection successfully but the page still won't load or throws errors (such as invalid certificate, handshake timeout, 502 error), then the network and port themselves are working. At this point, don't keep focusing on the network layer—instead, dig into whether the SSL/TLS certificate matches, whether SNI is configured correctly, the reverse proxy configuration, and the upstream application service status.

IPv6 Port 22 (SSH Remote Management)

Port 22 is typically used for SSH remote administration of Linux servers.

Many administrators, after configuring IPv6, often find that SSH connections work smoothly over IPv4 but time out immediately when switching to an IPv6 address. Repeatedly running Ping commands in this situation rarely reveals the root cause.

When IPv6 port 22 is unreachable, the key is to check the listening strategy of the sshd service on the Linux system. Many Linux distributions' default sshd_config only listens on IPv4 addresses (for example, only configuring ListenAddress 0.0.0.0) without explicitly declaring IPv6 address listening (ListenAddress ::).

In this case, even if the cloud server has a valid public IPv6 address and the security group allows port 22, the system's internal SSH daemon simply doesn't handle IPv6 connection requests—so all external IPv6 remote connection attempts will naturally fail.​

5. How Do You Interpret IPv6 Port Test Results?

Port testing doesn't just produce "success" and "failure"—different errors often point to completely different troubleshooting directions.

6. Why Does IPv6 Ping Work but the Port Is Unreachable?

If you've confirmed that the IPv6 address can be pinged successfully but the specified service port (such as 80, 443, 22, etc.) still can't establish a connection, the problem usually lies in service configuration, firewall policy, or network routing. Here are the six most common areas to investigate:

1. The Service Only Listens on an IPv4 Address

This is an extremely common and easily overlooked configuration oversight on dual-stack servers. Even though the server system has obtained a public IPv6 address, the specific application (such as Nginx, Apache, sshd, etc.) hasn't enabled listening on the IPv6 address.

For example, if the web server configuration file only sets listen 0.0.0.0:443, that means it only accepts requests on all IPv4 interfaces and hasn't created a corresponding IPv6 listener.

This configuration produces a very typical failure pattern:

• IPv4 port 443: Accessible normally

• IPv6 address Ping: Responds normally

• IPv6 port 443: Connection times out or is refused

This issue has nothing to do with external ISP lines—the root cause is entirely in the server's internal service configuration. On Linux systems, you can quickly check port listening details with:

ss -lntp

In the output, pay attention to whether the target port is bound in IPv4 format (such as 0.0.0.0:443) or includes IPv6 dual-stack binding format (such as [::]:443 or :::443).

2. Cloud Server Security Group Missing IPv6 Allow Rules

On cloud platforms like Alibaba Cloud, Tencent Cloud, and AWS, security group rules typically separate IPv4 and IPv6 into two independently configured tabs.

Many administrators, when deploying services, fully configure IPv4 inbound rules (allowing TCP 80, 443, 22, etc.) but forget to add corresponding allow policies in the IPv6 inbound rules.

In this case, even if the server has a valid public IPv6 address and ICMP traffic (Ping) is allowed by default, external TCP port connection requests will be blocked directly at the cloud platform's virtual gateway. Therefore, when updating cloud server security rules, always verify the IPv6 inbound rule list.

3. Server System Internal Firewall Blocking

Beyond the cloud platform's perimeter security groups, the server operating system's internal firewall also performs a second round of packet filtering.

nftables, iptables/ip6tables on Linux, or Windows Defender Firewall may all have separate rules applied to IPv6 traffic.

The complete path for an external request to reach the server application is typically:

Client request → Cloud platform security group → System internal firewall → Application listening port

In this chain, if any link has a filtering policy (DROP or REJECT), TCPing detection will fail. When troubleshooting, don't just check the cloud provider's console—you also need to log into the server to confirm the internal firewall's allow status.

4. Domain AAAA Record Points to the Wrong IPv6 Address

If you're testing port connectivity through a domain name, you also need to carefully verify DNS resolution settings.

On dual-stack sites, the domain typically has both an A record (pointing to IPv4) and an AAAA record (pointing to IPv6). If the IPv4 A record points correctly but the AAAA record still contains an old server, expired node, or incorrect IPv6 address, IPv4 access will work perfectly while IPv6 access consistently times out.

In this case, the server itself and port configuration may both be fine—the client request is simply being directed to the wrong node. Before testing a domain's IPv6 port, it's advisable to first check the actual resolved address using dig AAAA example.com or nslookup -type=AAAA example.com.

5. Incomplete IPv6 Configuration on CDN, WAF, or Reverse Proxy

If the website frontend uses CDN acceleration, high-defense IP, or WAF protection, the client is actually connecting to the edge node's IPv6 address, not the origin server's real IP.

The data transmission process becomes:

User client → IPv6 network → CDN/WAF edge node → Origin server

When IPv6 port 443 is unreachable, you need to confirm whether IPv6 support is enabled in the CDN console, whether the edge node's AAAA record resolution is in effect, and whether the CDN-to-origin back-to-source configuration is correct. If the CDN edge node fails to properly handle IPv6 connections, you'll see the origin server's IPv6 port working fine but the website becoming inaccessible after going through the CDN proxy.

6. IPv6 Backbone Routing or ISP Line Differences

The last scenario involves abnormal network transmission paths.

IPv6 and IPv4 belong to two relatively independent network systems, and the backbone routes, cross-network interconnection nodes, and ISP policies they traverse are not entirely consistent.

If online multi-node TCPing tests reveal results like the following:

• Beijing Telecom: Port 443 normal

• Shanghai Unicom: Port 443 normal

• Zhejiang Telecom: Port 443 normal

• Guangzhou Mobile: Port 443 timeout

• Shenzhen Mobile: Port 443 timeout

This pattern of localized node timeouts typically indicates that the server port and security group configuration are fine. Blindly restarting services or modifying firewall configurations often won't help. A more reasonable approach is to use multi-node detection tools and IPv6 Traceroute to further pinpoint exactly at which ISP backbone level packet loss or routing loops are occurring.​

7. How Should You Troubleshoot an Unreachable IPv6 Port?

When you encounter an unreachable IPv6 port, it's not advisable to start by modifying server configurations. Following a fixed troubleshooting order is usually much faster. The entire process can be organized as:

Query AAAA record
       ↓
Confirm IPv6 address
       ↓
Ping IPv6
       ↓
Test target TCP port
       ↓
Do all nodes fail on the port?
       ↓
 ┌─────┴─────┐
 Yes          No
 ↓            ↓
Check server  Compare abnormal regions
 ↓            ↓
Service listener  IPv6 routing
 ↓            ↓
Security group    ISP network
 ↓
System firewall
 ↓
CDN / WAF
 ↓
Re-run multi-node test

First, query the domain's AAAA record to confirm whether it already points to the correct IPv6 address.

Next, test basic IPv6 connectivity. If you can't even reach the IPv6 address itself, you should first sort out address configuration, the IPv6 gateway, routing, or carrier network issues—not jump straight to inspecting the web server.

If Ping looks basically fine, move on to testing the actual TCP ports in use. For example, check 80 and 443 for a website, and 22 for SSH.

At this point, don't rely only on results from your own computer.

If Chahu's multi-node TCPing shows that multiple nodes across the country and overseas all fail to connect, you can focus on checking the server's service listeners, security groups, and system firewall. If most nodes are fine and only a few regions fail, you should lean toward network path and carrier differences rather than concluding the port isn't open. Chahu currently offers TCP port connectivity and multi-node detection, which is well suited for this layer of cross-verification.

If the TCP port connects normally but the browser still throws an error, the problem may have moved past the network and transport layers, and you need to keep checking TLS, HTTP status, certificates, reverse proxy, and the application service.

In practice, separating these layers is often more effective than repeatedly tweaking configuration:

DNS
 ↓
IPv6 network
 ↓
TCP port
 ↓
TLS
 ↓
HTTP / application

Whichever layer first shows an anomaly is the layer to start investigating from.

Conclusion

What an IPv6 port test really needs to confirm isn't whether the server "has IPv6," but whether users can connect to the actual business port over an IPv6 network. An IPv6 address responding to Ping only shows that basic network reachability exists under the current test environment—it doesn't prove that TCP ports like 80, 443, and 22 are properly open to the outside.

When a website won't load over IPv6, SSH won't connect, or an API times out, a more practical troubleshooting approach is to first confirm AAAA resolution, then check basic IPv6 connectivity, and then test the corresponding business port with TCPing. If a single network test looks fine, you should still compare results across multiple regions and carrier nodes. Only then can you gradually determine whether the problem lies in the IPv6 address, the TCP port, the server's security policy, the service listener, or the IPv6 network path in a particular region—rather than assuming the whole IPv6 service is fine just because one Ping succeeded.

Related Q&A

1. When scanning IPv6 ports with nmap, how does the command differ from scanning IPv4?

nmap requires -6 for IPv6, e.g. nmap -6 -p 80,443,22 2001:db8::1. Without -6 it defaults to IPv4 and you'll scan forever without hitting anything. If the target blocks Ping, add -Pn to skip host discovery. But honestly, nmap port scans are easily blocked by cloud provider security groups or firewalls as scanning behavior, so results aren't always accurate. It's best to manually confirm one or two ports with nc or TCPing first, then use nmap for a bulk look.

2. I added an IPv6 rule to my cloud server's security group, but the port still won't connect. Why?

First check whether the rule is on the "inbound" direction, the protocol is TCP, the port range is correct, and the source address isn't just your own IP—during testing you can start with ::/0. Many cloud platforms keep IPv4 and IPv6 security groups separate; if you changed the IPv4 set but left the IPv6 set untouched, it's as if nothing was allowed. Also confirm the instance actually has a public IPv6 assigned and the subnet route points correctly. After changes, wait a minute or two before testing.

3. How do I configure Nginx to listen on both IPv4 and IPv6 for port 443?

In the server block, write two lines: listen 443 ssl; and listen [::]:443 ssl;. If you want a single listener to handle both IPv4 and IPv6, you can write listen [::]:443 ssl ipv6only=off;. After changes, run nginx -t to test, then reload. Then use ss -lntp | grep 443 to see if [::]:443 is present. If you only see 0.0.0.0:443, IPv6 definitely won't connect.

4. How do I test HTTPS with curl using a specific IPv6 address, without relying on DNS?

Use --resolve to specify directly, e.g. curl -6 -v --resolve example.com:443:[2001:db8::1] https://example.com. This forces the connection through your specified IPv6 address even if the AAAA record isn't set up. Add -v to see TLS handshake and certificate details. If it connects but the certificate errors out, that's a TLS-layer issue and has nothing to do with whether the port is reachable.

5. An IPv6 port test shows timeout—how do I tell whether it's a firewall DROP or a routing failure?

Use traceroute6 or mtr -6 to inspect the path. If packets show all asterisks after a certain hop, it could be a routing black hole or packet loss on an intermediate device. If the last hop reaches the target server but the port still times out, it's most likely a firewall DROP. If it's REJECT, you'll usually get connection refused. However, ICMPv6 may also be disabled, so don't draw conclusions from just one type of result.