GIA线路和CN2线路怎么区分？访问异常时如何结合DNS、路由追踪与端口测试判断

判断“GIA线路和CN2线路怎么区分？简单辨别方法”，不能只看域名解析结果、IP归属地或一次 Ping 延迟。更可靠的做法是：先确认 DNS 返回了哪个地址，再针对该地址检查实际路由、自治系统编号（ASN）和 TCP 端口，最后结合服务器防火墙、Nginx 反向代理与应用日志定位故障。GIA 通常是服务商对高质量中国电信网络接入的产品称呼，行业命名并不完全统一；CN2 则是中国电信下一代承载网络的统称，二者不能仅凭一个标签直接下结论。

访问异常时，建议按照“DNS → 网络入口和目标 IP → 路由追踪 → TCP 端口 → 防火墙 → 反向代理和应用状态”的顺序排查。这样可以先排除低风险、影响面较小的问题，再判断究竟是解析错误、路径不可达、端口未开放，还是应用本身返回异常。下面的命令以 Linux 客户端和 Windows 客户端为例，example.com、203.0.113.10、443 均为示例，请替换为实际域名、IP 和端口。

一、开始前确认测试条件

先记录以下信息，避免把不同时间、不同解析结果或不同网络环境下的结果混在一起：

• 发生故障的完整域名，以及访问协议和端口，例如 https://example.com:443。
• 测试时间，并注明时区。
• 客户端系统、网络运营商或出口环境。
• 解析得到的全部 A 记录和 AAAA 记录。
• 服务端 IP、监听端口、是否使用 CDN、负载均衡或 Nginx 反向代理。
• 一个受影响的测试节点，以及条件允许时的一个正常测试节点。
• 服务器端对应时间段的访问日志、错误日志和应用日志。

图示对应原文命令：https://example.com:443。

如果需要判断线路，必须固定测试对象。不要一次测试域名，另一次直接测试不同的 IP；也不要把 IPv4 路由和 IPv6 路由混为一谈。线路和网络质量会随源地址、目的地址、时间、协议及运营商路由调整而变化，单次结果只能说明当时、当源、到当目的地址的路径。

二、第一步：确认 DNS 是否返回了预期入口

DNS 负责把域名映射到一个或多个 IP，它可以决定用户访问哪个网络入口，但 DNS 本身不能证明该 IP 一定是 GIA 或 CN2。

Linux 查询 A、AAAA 记录

dig example.com A +noall +answer
dig example.com AAAA +noall +answer

也可以查询本机当前使用的解析器：

resolvectl status
resolvectl query example.com

Windows 查询 A、AAAA 记录

nslookup -type=A example.com
nslookup -type=AAAA example.com

重点观察以下结果：

• 返回 NXDOMAIN：域名不存在或查询到了不包含该域名的权威结果。
• 返回 SERVFAIL：解析链路、权威 DNS 或 DNSSEC 等环节可能存在异常，需要进一步查看权威 DNS。
• A 记录为空但 AAAA 存在：仅支持 IPv6 的客户端可能可以访问，IPv4 客户端则可能失败。
• A 记录正常、AAAA 指向不可达地址：部分优先使用 IPv6 的客户端可能出现访问慢、超时或间歇性失败。
• 不同解析器返回不同 IP：可能存在 TTL 尚未同步、分线路解析、地域解析、故障切换或负载均衡。

图示对应原文命令：NXDOMAIN。

可分别强制使用 IPv4 和 IPv6 测试应用层连接：

curl -4 -I --connect-timeout 5 --max-time 15 https://example.com/
curl -6 -I --connect-timeout 5 --max-time 15 https://example.com/

这里的 -4 和 -6 只用于区分协议栈，不代表线路类型。若 IPv4 成功而 IPv6 超时，应优先检查 AAAA 记录、IPv6 路由、服务端 IPv6 监听和防火墙，而不是直接判断为 GIA 或 CN2 问题。

这一阶段的修复与验证

如果 DNS 返回了旧 IP 或错误 IP，应先在 DNS 管理端核对记录内容、TTL、线路分流条件和故障切换状态。修改前保存当前记录，避免误删其他业务记录。修改后不要立即把 DNS 正常解析当成访问恢复，还需要针对新 IP 继续做端口和 HTTP 测试。

如果域名解析正常，但访问仍然失败，记录每个 IP，分别进入下一步。一个域名对应多个 IP 时，其中一个入口异常就可能导致部分用户访问失败。

三、第二步：确认网络入口和实际目标 IP

网络入口至少包括客户端出口、DNS 返回的目标 IP，以及服务端前置设备。使用 CDN、负载均衡或 Nginx 反向代理时，客户端路由追踪到的通常是边缘或入口地址，不一定是源站地址。

Linux 上可以查看到目标 IP 的本地选路结果：

ip route get 203.0.113.10

输出中的 dev、src 和 via 可以帮助确认使用了哪个网卡、源地址和下一跳。Windows 可使用：

route print

如果同一台客户端连接了多个网络，或者系统同时启用了 IPv4 和 IPv6，应确认实际使用的源地址。服务端日志中的客户端源地址也可以帮助判断某个入口是否真正收到请求。

使用指定 IP 保留域名访问

为了绕过 DNS 结果、直接测试某个 IP，同时保留正确的 Host 和 TLS SNI，可以使用：

curl -vk --resolve example.com:443:203.0.113.10 \
  https://example.com/

说明：

• --resolve 仅对本次命令生效，不修改系统 DNS。
• -v 用于查看连接、TLS 和 HTTP 过程。
• -k 会跳过证书校验，只适合故障定位，不能作为正常访问成功的判断标准。
• 如果指定 IP 可以返回 HTTP 响应，而正常域名访问失败，应重点检查 DNS、SNI、证书绑定、入口分流或不同 IP 的配置差异。

如果指定 IP 也无法建立连接，再进行路由和端口测试。不要仅凭 IP 注册信息判断线路归属，因为 IP 所属机构与当次访问经过的实际网络路径不是同一个概念。

四、第三步：用路由追踪判断实际路径

路由追踪用于观察数据包从测试节点到目标 IP 的中间路径。它可以帮助发现路径中断、入口变化或运营商网络段，但不能单独证明一条线路就是 GIA。

Linux 使用 TCP 路由追踪

网页访问通常使用 TCP 443 端口，因此可以优先使用 TCP 路由追踪：

traceroute -n -T -p 443 203.0.113.10

如果系统没有 traceroute，或者 TCP 探测不适用，可以尝试：

tracepath -4 203.0.113.10

需要观察较稳定的路径段、最后几个响应节点和是否到达目标地址。* 不一定代表链路中断，很多路由器会限制 ICMP 或 TTL 超时报文的响应。只有当目标端口测试也失败，并且多个探测结果在同一位置停止时，路径异常的可能性才会增加。

使用 MTR 观察丢包位置

mtr -rwzc 30 -T -P 443 203.0.113.10

该命令使用 TCP 443 探测，-c 30 表示进行 30 次探测。它只是一次诊断样本，不代表长期线路质量。判断时重点看：

• 某个中间节点丢包，但后续节点和目标地址没有持续丢包：通常是该节点限制探测响应，不宜直接认定链路丢包。
• 从某一跳开始，后续所有节点和目标地址都持续丢包：可能存在路径中断、过滤或目标入口不可达。
• 只有目标地址持续丢包：需要同时核对端口监听、防火墙和服务端状态。
• 路径前后多次变化：可能是负载均衡、路由收敛或不同探测协议导致，不能直接归因于线路优劣。

Windows 可以使用：

tracert -d 203.0.113.10
Test-NetConnection 203.0.113.10 -Port 443 -InformationLevel Detailed

tracert 主要观察路径，Test-NetConnection 用于验证指定 TCP 端口，二者应结合使用。

五、如何从路由结果区分 GIA 与 CN2

常见的简单辨别方法是检查路由中的 ASN 和关键网络段，但必须把它当作线索，而不是单一结论。

在公开路由识别中，AS4809 经常与中国电信 CN2 相关网络段联系在一起，AS4134 也常被用于中国电信传统 ChinaNet/163 相关路径的标识。实际路径可能包含转接、互联、负载均衡和临时绕路，因此看到某个 ASN 并不等于已经证明整条线路的产品属性。

可以按下面的方式判断：

若要确认服务商宣称的 GIA 或 CN2 属性，应要求对方提供与当前业务 IP、测试时间和目标地区相对应的路由说明，并自行从受影响节点执行 TCP 路由追踪。最好同时进行服务端反向追踪：

traceroute -n -T -p 443 <客户端公网IP>

服务端反向追踪需要具备合法的服务器管理权限，且服务端到客户端的路径不一定与客户端到服务端相同。只有去程、回程、源地址、目标地址和测试时间都对应时，结果才有比较价值。

六、第四步：测试 TCP 端口，不要只测 Ping

网页访问失败时，优先测试实际业务端口。TCP 连接成功只能证明端口可以完成握手，不代表 TLS、HTTP 或应用一定正常。

Linux 测试端口

nc -vz -w 5 203.0.113.10 443
nc -vz -w 5 203.0.113.10 80

如果业务使用其他端口，将 443 替换为实际端口。常见结果含义如下：

• succeeded 或 open：TCP 端口可建立连接，可以继续检查 TLS、HTTP 和应用。
• Connection refused：目标主机可达，但端口没有监听，或设备主动拒绝连接。
• timed out：可能是路径不可达、防火墙丢弃、云侧访问控制或服务端无响应。
• DNS 失败：还没有进入端口测试阶段，应返回 DNS 步骤处理。

Windows 使用：

Test-NetConnection 203.0.113.10 -Port 443

重点查看 TcpTestSucceeded。如果返回 True，再测试完整 HTTPS 请求：

curl -vk --connect-timeout 5 --max-time 15 \
  https://example.com/

根据端口结果分流

• DNS 失败：检查域名记录、权威 DNS、解析分流和 TTL。
• DNS 正常、端口超时：检查目标入口、网络路径、上游 ACL、服务器防火墙和安全组。
• 端口拒绝：检查服务是否监听、监听地址是否正确、端口是否写错。
• 端口成功、TLS 失败：检查证书、SNI、TLS 配置和反向代理监听。
• TLS 成功、HTTP 返回 4xx：通常已到达 Web 层，应检查域名匹配、访问规则或应用权限。
• HTTP 返回 502/504：重点检查 Nginx 反向代理到后端应用的连接。
• HTTP 返回 5xx：查看应用日志、依赖服务和资源状态。

七、第五步：检查服务监听、防火墙和安全策略

这一步需要服务器管理权限。先做只读检查，不要为了验证线路直接清空或覆盖防火墙规则。

查看端口监听

sudo ss -lntp | grep -E ':(80|443)\b'

需要关注监听地址：

• 0.0.0.0:443：通常表示监听所有 IPv4 地址。
• [::]:443：通常表示监听 IPv6 地址，具体行为还取决于系统参数。
• 127.0.0.1:443：只接受本机连接，外部用户无法直接连接，除非由前置入口转发。
• 没有监听记录：服务未启动、端口配置错误或服务启动失败。

查看 Nginx 和系统日志

sudo systemctl status nginx --no-pager
sudo nginx -t
sudo journalctl -u nginx --since "30 minutes ago" --no-pager

日志路径可能因发行版和配置不同而变化，常见位置包括：

sudo tail -n 50 /var/log/nginx/access.log
sudo tail -n 50 /var/log/nginx/error.log

如果 Nginx 正常监听但返回 502 或 504，应检查 upstream 地址、后端监听端口、后端进程和本机连接：

sudo ss -lntp
curl -v http://127.0.0.1:<后端端口>/

最后一条命令只适用于后端提供 HTTP 服务的情况，请替换为实际端口和路径。

检查防火墙状态

根据发行版选择对应的只读命令：

sudo nft list ruleset

sudo ufw status verbose

sudo firewall-cmd --state
sudo firewall-cmd --list-all

还要检查云平台安全组、上游防护设备或机房边界 ACL 是否允许受影响源地址访问目标端口。若只有某个来源网络失败，而其他来源正常，尤其要核对按源地址、地区或端口设置的访问规则。

任何防火墙调整都应先导出或保存现有规则，明确影响范围，并准备恢复原规则的方法。不要使用“清空全部规则后再测试”的方式排障，这可能导致 SSH、Web 或其他业务同时中断。

八、第六步：检查反向代理与应用状态

当 TCP 端口开放、TLS 握手成功，但浏览器仍提示访问失败时，问题通常已经进入 Web 或应用层。

使用 curl 查看完整过程：

curl -vk --connect-timeout 5 --max-time 15 \
  -H 'Host: example.com' \
  https://203.0.113.10/

如果 HTTPS 使用了多个域名或证书，优先使用前面的 --resolve 方式，因为它能够同时保留域名和 TLS SNI。

根据状态码判断：

• 200、204：应用完成了正常响应，继续核对页面内容或前端资源。
• 301、302：网络和 Web 服务基本可达，检查跳转目标是否解析正常、协议是否循环跳转。
• 400、403、404：请求已到达 Web 层，重点检查域名匹配、路径、访问规则和应用路由。
• 502：反向代理通常无法获得后端有效响应，检查后端进程、端口和协议。
• 504：反向代理等待后端超时，检查后端处理时间、依赖服务和网络连接。
• 500 或其他 5xx：查看应用自身日志和相关依赖，不要继续把问题归因于 GIA 或 CN2。

将客户端请求时间与 Nginx access log、error log 和应用日志对齐。如果客户端显示超时，但服务端完全没有对应访问记录，问题更可能发生在 DNS、网络入口、路径或端口之前；如果日志中有请求但返回 5xx，则应转向应用层处理。

九、修复后的验收方法

修复 DNS、路由入口、防火墙或应用配置后，应使用与故障发生时尽量相同的测试条件复核，不要只刷新一次浏览器。

建议按以下顺序验收：

1. 再次查询 A 和 AAAA，确认返回的是预期 IP，且没有遗留错误入口。
2. 从原受影响测试节点分别测试 IPv4 和 IPv6。
3. 对每个实际入口执行 TCP 端口测试。
4. 使用 curl --resolve 对每个 IP 发起带正确域名和 SNI 的 HTTPS 请求。
5. 检查 HTTP 状态码、证书域名、响应时间和页面关键内容。
6. 在服务端日志中确认请求已经到达正确的 Nginx 或负载均衡入口。
7. 若使用反向代理，确认后端应用收到请求并返回正常状态。
8. 在记录的时间、源地址、目标 IP 和探测方法一致的前提下，再比较路由路径。

线路验收不能只看一次 Ping，也不能把某个 ASN 的出现当成性能承诺。若需要确认 GIA 或 CN2 属性，应保留以下证据：

• 测试节点和出口信息；
• 测试时间；
• A、AAAA 解析结果；
• 目标 IP 和端口；
• TCP 路由追踪或 MTR 输出；
• 关键路径中的 ASN；
• 去程和条件允许时的回程路径；
• 端口测试与 HTTP 响应结果。

这些信息只能说明特定时间、特定源地址到特定目标地址的观察结果，不能推导所有地区、所有运营商或所有时间段的固定表现。

十、配置变更后的回滚检查

如果排障期间修改过 DNS、Nginx 或防火墙，应在处理前保存旧配置，并记录修改时间和变更内容。

• DNS：恢复原有记录和分流规则，确认 TTL 与权威 DNS 配置一致。
• Nginx：恢复变更前的配置，先执行配置检查，再进行平滑加载。
• 防火墙：使用变更前保存的规则恢复，不要用空规则集替代原策略。
• 应用：恢复环境变量、监听端口或上游地址后，检查进程状态和日志。
• 路由或入口：撤回错误的 IP、负载均衡成员或访问控制项，确认其他正常入口没有被一并移除。

Nginx 配置回滚时，可在确认备份文件路径正确后执行：

sudo nginx -t
sudo systemctl reload nginx

reload 会重新加载配置，执行前应确认当前服务器由 Nginx 提供的业务范围，并确保配置文件已备份。若 nginx -t 未通过，不要继续加载配置。

最终应再次完成 DNS、端口、HTTPS、反向代理和应用日志检查。只有当域名解析、TCP 连接、TLS、HTTP 响应以及后端应用均恢复，且受影响测试节点能够稳定复现正常结果时，才可以把故障标记为已处理；线路类型的判断则仍应以当次完整路由和服务商可核验的网络说明为依据。