IPv6 端口怎么测试？在线检测 80、443、22 端口是否开放

服务器已经配置了 IPv6，域名的 AAAA 记录也解析正常，Ping IPv6 地址时还能收到响应，但网站就是打不开，SSH 也连接不上。遇到这种情况，继续反复 Ping 往往查不出真正的问题。因为IPv6 地址可以访问，不代表服务器上的业务端口一定可以连接。

Ping 主要用来判断 IPv6 网络是否基本可达，而网站、SSH、API 等服务最终依赖的是具体 TCP 端口。例如 HTTPS 网站通常需要连接 443 端口，HTTP 使用 80 端口，SSH 常见的是 22 端口。如果服务器只允许 ICMP，却没有放行对应 TCP 端口，就可能出现“IPv6 Ping 正常，但网站访问失败”的情况。

所以，在确认 IPv6 基础连通性之后，下一步通常就是做 IPv6 端口测试。本文将从 IPv6 端口测试方法入手，具体介绍 80、443、22 等常见端口怎么检测、测试结果怎么看，以及遇到 IPv6 能 Ping 通但端口不通时应该如何排查。

一、为什么 IPv6 能 Ping 通，端口却不一定能访问？

在 IPv6 网站部署和服务器运维中，不少人都会遇到一个奇特现象：在终端里执行 IPv6 Ping 命令，明明能收到正常的延迟响应，但用浏览器打开网站却一直提示超时，甚至用终端连接 SSH 也直接报错。

这种“IPv6 能够 Ping 通，但服务端口打不开”的情况其实非常常见。

出现这个问题，本质上是因为 Ping 和网站访问验证的完全是两个不同层级的网络环节。

当我们试图通过 IPv6 访问一个网站或者远程服务器时，整个数据传输流程实际上需要按顺序通过以下几个关卡：

1. IPv6 地址链路可达（基础网络连通）

2. TCP 端口建立连接（传输层通道开启）

3. TLS / SSH 协议握手（加密与身份验证）

4. 应用服务返回响应（Web / SSH 服务正常工作）

Ping 命令的作用，仅仅是验证了第一关。

Ping 使用的是 ICMPv6 协议，它的主要职责是测试本地设备到目标 IPv6 地址之间的网络通路是否通畅。只要网卡配置了 IPv6 地址、网关无误且沿途路由器没有拦截 ICMP 包，Ping 就能返回漂亮的响应延迟。

但这并不意味着后面的关卡也是畅通的。

比如常见的 HTTPS 网站，它依赖传输层的 TCP 443 端口；HTTP 依赖 80 端口；而 SSH 远程管理则依赖 22 端口。如果在服务器端，系统防火墙拦截了 TCP 443 的入站流量，或者 Web 服务本身根本没有在 IPv6 地址上开启监听，就会导致非常典型的故障现象：

• IPv6 Ping 测试：正常响应（延迟 28ms）

• TCP 443 端口测试：连接超时

• HTTPS 网站访问：无法打开

反过来的情况也同样成立。出于安全考虑，很多企业级服务器和数据中心机房会直接禁用 ICMP Echo 响应。此时去 Ping 服务器的 IPv6 地址会全部显示超时，但只要服务器放行了 TCP 端口，HTTPS 网站和 SSH 服务依然能够正常访问。

因此，在排查 IPv6 网站打不开或服务连接失败等故障时，不能把 Ping 的结果作为服务是否可用的唯一标准。确认 IPv6 地址能够到达之后，更关键的一步是针对具体的 TCP 业务端口进行深入检测。

二、IPv6 端口测试到底在测试什么？

所谓 IPv6 端口测试，本质上是在判断：测试设备能否通过 IPv6 网络，与目标服务器指定的 TCP 端口建立连接。

这里涉及两个关键条件：一个是 IPv6 网络本身能够到达目标服务器；另一个是服务器对应端口确实处于可连接状态。

不同业务需要检查的端口也不同。

Ping 和 IPv6 端口测试有什么区别？

很多人排查 IPv6 问题时最容易混淆的就是 Ping 和 TCP 端口检测，两者虽然都可以判断“网络通不通”，但测试的层级不同。

例如网站访问异常时，如果 IPv6 Ping 正常，下一步就不应该继续盯着 Ping 延迟，而应该直接测试 80 或 443 端口。这也是为什么服务器能够 Ping 通，却依然可能打不开网站。

三、IPv6 端口怎么测试？

IPv6 端口测试并不复杂。临时排查可以使用 Windows、Linux 自带的命令，如果需要判断不同地区、不同运营商访问同一个 IPv6 端口是否存在差异，则更适合配合在线 TCPing。

1. 使用 Chahu 在线 TCPing 测试 IPv6 端口

如果想从公网环境检查服务器端口，可以使用 Chahu 的 TCPing：

https://www.chahu.com/tcping

Chahu 的 TCPing 主要用于检测指定 TCP 端口的连通状态和连接耗时，并可以从不同地区及运营商节点进行测试。相比只在自己电脑上连接一次，这种方式更容易判断端口异常究竟是服务器本身的问题，还是只出现在某些网络环境。

实际测试逻辑并不复杂：

输入域名或 IPv6 地址
        ↓
填写需要检测的 TCP 端口
        ↓
开始 TCPing
        ↓
查看不同节点连接结果
        ↓
判断是全部失败还是部分地区异常

比如测试 HTTPS 网站，就重点检查 443 端口；SSH 无法连接，则检查 22 端口。

真正值得看的不仅是“能不能连接”，还包括不同地区的结果是否一致。

假设检测结果类似：

北京电信       443 正常
上海联通       443 正常
杭州移动       443 正常
广州移动       443 超时
深圳移动       443 超时

这种情况就不能简单理解为“443 端口没有开放”。因为如果端口真的完全关闭，通常不会只有个别线路出现问题。此时还需要继续考虑 IPv6 路由、运营商网络或者中间安全策略。

2. Windows 测试 IPv6 端口

Windows 可以直接通过 PowerShell 的Test-NetConnection测试 TCP 端口。

例如检查 IPv6 服务器的 443 端口：

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

运行后重点看：

TcpTestSucceeded : True

如果结果为：True说明当前电脑通过 IPv6 到目标服务器的 TCP 443 基本可以建立连接；如果是：False 就需要继续检查端口监听、防火墙、安全组以及 IPv6 网络路径。

对于域名也可以直接测试：

Test-NetConnection example.com -Port 443

不过在双栈网站中，域名可能同时存在 A 和 AAAA 记录。如果目的是专门排查 IPv6，最好同时确认实际连接使用的地址，避免把 IPv4 测试结果误认为 IPv6 结果。

3. Linux 测试 IPv6 端口

Linux 下可以使用nc。

例如测试 IPv6 443 端口：

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

测试 SSH：

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

其中：

-6    强制使用 IPv6
-v    显示详细结果
-z    只检查端口，不发送业务数据

如果检测 HTTPS 网站，还可以进一步使用：

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

这一条就不只是判断 TCP 443 能不能连接了，而是继续检查 IPv6 环境下 HTTPS 服务能否正常建立连接并返回 HTTP 响应。

因此实际排查时可以逐层进行：IPv6 Ping→ TCP 443→ TLS→ HTTP Response

问题出现在哪一层，排查范围也会小很多。

四、IPv6 80、443、22 端口分别怎么判断？

在实际排查过程中，不同业务端口对应的访问链路和排查重点其实各有侧重。下面针对 80、443 和 22 这三个最核心的端口，分别梳理具体的操作思路和判断逻辑。

IPv6 80 端口（HTTP 服务）

80 端口是传统 HTTP Web 服务的基础端口。用户通过 80 端口发起访问的底层数据流向大致为：

用户客户端 → IPv6 传输链路 → TCP 80 端口握手 → Web 服务器进程（如 Nginx/Apache）→ 返回 HTTP 响应

如果在测试时发现 IPv6 Ping 完全正常，但 TCP 80 端口始终响应超时，最常见的排查方向有两个：

1. 服务监听遗漏：Web 服务可能只绑定了 IPv4 地址（0.0.0.0:80），未开启 IPv6 监听；

2. 策略拦截：云服务器平台的 IPv6 入站安全组规则或系统内部防火墙（如ip6tables、nftables）未放行 TCP 80 端口。

需要注意的是，现在绝大部分网站都开启了全站 HTTPS，通常会将 80 端口的流量通过 301 或 302 强制重定向至 443 端口。因此，80 端口测试成功仅代表 HTTP 基础通路没问题，并不能直接推断出 443 端口也同样可用，两者必须独立进行验证。

IPv6 443 端口（HTTPS 服务）

443 端口是当前 IPv6 网站故障排查中最高频、也最容易遇到复杂问题的环节。相比普通 HTTP，一次完整的 HTTPS 访问需要经过更严谨的协议交互：

IPv6 基础网络 → TCP 443 端口连接 → TLS/SSL 加密握手 → 发送 HTTPS 请求 → Web 服务器处理并响应

在排查 443 端口时，必须清晰区分两种截然不同的故障现象：

• TCP 443 端口连接失败（超时或拒绝）：这属于典型的传输层及网络层故障。排查优先级应放在云服务器安全组、系统防火墙、CDN 边缘节点配置以及 IPv6 路由线路上。

• TCP 443 端口正常，但浏览器提示 HTTPS 错误：如果通过 TCPing 确认 443 端口可以顺利建立连接，但网页依旧打不开或报错（如证书无效、握手超时、502 错误），则说明网络和端口本身已经通畅。此时不应再纠结于网络层，而应深入检查 SSL/TLS 证书是否匹配、SNI 配置是否正确、反向代理配置以及上游应用服务的运行状态。

IPv6 22 端口（SSH 远程管理）

22 端口通常用于 Linux 服务器的 SSH 远程运维管理。

许多管理员在配置 IPv6 后，经常遇到 IPv4 下 SSH 连接流畅，但换成 IPv6 地址后直接提示连接超时。此时去反复执行 Ping 命令其实很难找到根本原因。

遇到 IPv6 22 端口不通时，重点应检查 Linux 系统中sshd服务的监听策略。许多 Linux 发行版默认的sshd_config配置只监听了 IPv4 地址（例如仅仅配置了ListenAddress 0.0.0.0），并没有显式声明对 IPv6 地址（ListenAddress ::）进行监听。

在这种情况下，即便云服务器拥有合法的公网 IPv6 地址且安全组放行了 22 端口，由于系统内部的 SSH 守护进程根本不处理 IPv6 的连接请求，外部通过 IPv6 进行的远程连接尝试自然会全部失败。​

五、IPv6 端口测试结果怎么看？

端口测试不是只有“成功”和“失败”两种结果，不同错误往往对应完全不同的排查方向。

六、为什么 IPv6 Ping 正常，但端口不通？

如果确认 IPv6 地址能够成功 Ping 通，但指定的业务端口（如 80、443、22 等）仍然无法建立连接，问题通常出在服务配置、防火墙策略或网络路由层面。以下是六个最常见的排查方向：

1. 业务服务仅监听了 IPv4 地址

这是双栈服务器上极为普遍且容易被忽视的配置疏漏。服务器系统层面虽然已经获取到了公网 IPv6 地址，但具体的应用程序（如 Nginx、Apache、sshd 等）并没有开启对 IPv6 地址的监听。

例如，Web 服务器的配置文件中如果只设置了监听0.0.0.0:443，这就意味着它仅在 IPv4 的所有接口上接收请求，而没有建立对应的 IPv6 监听器。

这种配置会导致非常典型的故障现象：

• IPv4 443 端口：正常访问

• IPv6 地址 Ping：响应正常

• IPv6 443 端口：连接超时或被拒绝

此问题与外部运营商线路无关，根源完全在服务器内部的服务配置。在 Linux 系统中，可以通过以下命令快速查看端口监听详情：

ss -lntp

在输出结果中，重点观察目标端口绑定的是 IPv4 格式（如0.0.0.0:443），还是包含 IPv6 双栈绑定格式（如[::]:443或:::443）。

2. 云服务器安全组缺少 IPv6 放行规则

在阿里云、腾讯云、AWS 等云平台上，安全组规则通常将 IPv4 与 IPv6 划分为两个独立配置的标签页。

不少管理员在部署服务时，完整配置了 IPv4 入站规则（放行 TCP 80、443、22 等），却忘记在 IPv6 入站规则中添加对应的放行策略。

在这种情况下，即便服务器拥有合法的公网 IPv6 地址，且 ICMP 流量（Ping）默认被允许，外部发起的 TCP 端口建连请求也会在云平台的虚拟网关处被直接拦截。因此，更新云服务器的安全规则时，务必核对 IPv6 入站规则列表。

3. 服务器系统内部防火墙拦截

除了云平台外围的安全组之外，服务器操作系统内部的防火墙同样会对数据包进行二次过滤。

Linux 系统中的nftables、iptables/ip6tables，或者 Windows 系统的 Defender 防火墙，都有可能针对 IPv6 流量应用了单独的规则。

外部请求到达服务器程序的完整路径通常为：

客户端请求 → 云平台安全组 → 系统内部防火墙 → 应用程序监听端口

在这条链路中，任何一环设置了过滤策略（DROP 或 REJECT），TCPing 检测都会宣告失败。排查时不能仅查看云厂商的控制台，还需登录服务器确认系统内部防火墙的放行状态。

4. 域名 AAAA 记录指向错误的 IPv6 地址

如果是通过域名测试端口连通性，还需要仔细核对 DNS 解析设置。

在双栈站点中，域名通常同时配置了 A 记录（指向 IPv4）和 AAAA 记录（指向 IPv6）。如果 IPv4 的 A 记录指向无误，但 AAAA 记录仍然残留着旧服务器、过期节点或错误的 IPv6 地址，就会导致 IPv4 访问完全正常，而 IPv6 访问始终超时。

此时服务器本身和端口配置可能都是正常的，只是客户端请求被引导到了错误的节点上。在测试域名 IPv6 端口前，建议先通过dig AAAA example.com或nslookup -type=AAAA example.com查询实际解析出的地址。

5. CDN、WAF 或反向代理的 IPv6 配置不完整

如果网站前端接入了 CDN 加速、高防 IP 或 WAF 防护，客户端实际连接的是边缘节点的 IPv6 地址，而非源站真实 IP。

数据传输过程变为：

用户客户端 → IPv6 网络 → CDN/WAF 边缘节点 → 源站服务器

当出现 IPv6 443 端口不通时，需要确认 CDN 控制台中是否已开启 IPv6 支持、边缘节点的 AAAA 记录解析是否生效，以及 CDN 到源站的回源配置是否正常。如果 CDN 边缘节点未能正确处理 IPv6 连接，就会出现源站 IPv6 端口本身正常，但经过 CDN 代理后反而打不开网站的情况。

6. IPv6 骨干网路由或运营商线路差异

最后一种情况属于网络传输路径异常。

IPv6 与 IPv4 属于两套相对独立的网络体系，二者所走的骨干网路由、跨网互联节点以及运营商策略并不完全一致。

如果通过在线多节点 TCPing 测试时，发现类似如下的结果：

• 北京电信：443 端口 正常

• 上海联通：443 端口 正常

• 浙江电信：443 端口 正常

• 广州移动：443 端口 超时

• 深圳移动：443 端口 超时

这种局部节点超时的现象，通常表明服务器端口和安全组配置是没有问题的。此时盲目重启服务或修改防火墙配置往往无济于事，更合理的方式是借助多节点检测工具和 IPv6 Traceroute 路由追踪，进一步定位数据包究竟是在哪一级运营商骨干网出现了丢包或路由环路。​

七、IPv6 端口不通应该怎么排查？

碰到 IPv6 端口无法连接时，不建议一上来就修改服务器配置。按照固定顺序排查，通常会快很多，整个过程可以整理成：

查询 AAAA 记录
       ↓
确认 IPv6 地址
       ↓
Ping IPv6
       ↓
测试目标 TCP 端口
       ↓
端口是否全部节点失败？
       ↓
 ┌─────┴─────┐
 是           否
 ↓            ↓
检查服务器    对比异常地区
 ↓            ↓
服务监听      IPv6 路由
 ↓            ↓
安全组        运营商网络
 ↓
系统防火墙
 ↓
CDN / WAF
 ↓
重新进行多节点测试

首先查询域名的 AAAA 记录，确认它是否已经指向正确的 IPv6 地址。

接着测试 IPv6 基础连通性。如果连 IPv6 地址本身都无法到达，就应该先解决地址配置、IPv6 网关、路由或者运营商网络问题，而不是直接检查 Web Server。

如果 Ping 基本正常，再继续测试真正使用的 TCP 端口。例如网站检查 80 和 443，SSH 检查 22。

这时候不要只看自己电脑的结果。

如果 Chahu 多节点 TCPing 显示全国及海外多个节点全部无法连接，可以重点回服务器检查服务监听、安全组以及系统防火墙；如果大部分节点正常，只有少数地区失败，则更应该考虑网络路径和运营商差异，而不是直接认定端口没有开放。Chahu 当前提供 TCP 端口连通性及多节点检测能力，适合用来做这一层交叉验证。

如果 TCP 端口已经正常建立连接，但浏览器依然报错，则说明问题可能已经越过网络层和传输层，需要继续检查 TLS、HTTP 状态、证书、反向代理以及应用服务。

实际排查时，把这几层分开往往比反复修改配置更有效：

DNS
 ↓
IPv6 网络
 ↓
TCP 端口
 ↓
TLS
 ↓
HTTP / 应用

在哪一层第一次出现异常，就从哪一层开始继续查。

结语

IPv6 端口测试真正要确认的，并不是服务器“有没有 IPv6”，而是用户通过 IPv6 网络能不能连接到实际使用的业务端口。一个 IPv6 地址能够正常 Ping，只能说明基础网络在当前测试环境下具备一定的可达性，并不能证明 80、443、22 等 TCP 端口已经对外正常开放。

遇到网站 IPv6 打不开、SSH 无法连接或者 API 超时时，更实用的排查方式是先确认 AAAA 解析，再检查 IPv6 基础连通性，随后通过 TCPing 测试对应业务端口。如果单一网络测试正常，还应继续通过多个地区和运营商节点进行对比。这样才能逐步判断问题到底出在 IPv6 地址、TCP 端口、服务器安全策略、服务监听，还是某个地区的 IPv6 网络路径，而不是看到一次 Ping 成功就认为整个 IPv6 服务已经正常。

相关问答

1. 用 nmap 扫 IPv6 端口，命令和扫 IPv4 有啥不一样？

nmap 扫 IPv6 必须加 -6，比如 nmap -6 -p 80,443,22 2001:db8::1。不加 -6 它默认走 IPv4，你扫半天也扫不到。如果目标禁 Ping，加 -Pn 跳过主机发现。但说实话，nmap 扫端口容易被云厂商安全组或防火墙当扫描行为拦掉，结果不一定准。最好先拿 nc 或 TCPing 手动确认一两个端口，再用 nmap 批量看。

2. 云服务器安全组加了 IPv6 规则，为什么端口还是不通？

先看规则是不是加在“入方向”，协议选 TCP，端口范围写对，源地址别只写自己的 IP，测试时可以先放 ::/0。很多云平台 IPv4 和 IPv6 安全组是分开的，你改完 IPv4 那套，IPv6 那套没动，等于没放行。还要确认实例真的分配了公网 IPv6，子网路由也指对了。改完等一两分钟再测。

3. Nginx 怎么配置才能同时监听 IPv4 和 IPv6 的 443？

在 server 块里写两行：listen 443 ssl; 和 listen [::]:443 ssl;。如果想一个监听同时吃 IPv4 和 IPv6，可以写 listen [::]:443 ssl ipv6only=off;。改完 nginx -t 测试，再 reload。然后用 ss -lntp | grep 443 看有没有 [::]:443。只有 0.0.0.0:443 的话，IPv6 肯定连不上。

4. 如何用 curl 指定 IPv6 地址测试 HTTPS，不依赖 DNS？

用 --resolve 直接指定，比如 curl -6 -v --resolve example.com:443:[2001:db8::1] https://example.com。这样就算 AAAA 记录没配好，也能强制走你指定的 IPv6 地址。加 -v 看 TLS 握手和证书细节。如果连上了但证书报错，那是 TLS 层的事，跟端口通不通没关系。

5. IPv6 端口测试显示 timeout，怎么判断是防火墙 DROP 还是路由不通？

用 traceroute6 或 mtr -6 看路径。如果数据包在某一跳之后全是星号，可能是路由黑洞或者中间设备丢包。如果最后一跳已经到目标服务器了，但端口还是 timeout，那大概率是防火墙 DROP。要是 REJECT，通常会返回 connection refused。不过 ICMPv6 也可能被禁，所以别只靠一种结果下结论。