连接云 VPN 后，业务网站仍可能出现无法打开、访问超时或页面加载不完整等问题。本文面向企业 IT 和网络管理员，介绍如何根据 cURL 的请求结果选择排查方向，并结合访问策略、CPE 日志和抓包结果定位异常。 ## 排查前准备本文适用于云 VPN 域名资源访问异常，不适用于纯 IP 资源访问异常或办公网基础网络中断。 * 开始排查前，确认终端已成功连接云 VPN。 * 本文中的管理后台和 CPE 检查由企业 IT 或网络管理员执行，操作 CPE 需具备相应设备管理权限。如果尚未成功连接 VPN，请先参见[VPN 连接排障](https://help.feilian.cn/help-center/vpn-connection-troubleshooting-guide)。 * 记录故障发生时间、终端系统、飞连客户端版本、连接节点和受影响的用户范围，并准备一个可以复现问题的业务地址。后续测试应使用同一域名和端口，以便对比终端、浏览器和 CPE 的结果。 ## 判断故障现象先确认失败请求的域名，再使用 cURL 查看请求停在哪个阶段，最后根据结果选择对应章节。后续排查章节是不同故障现象的处理分支，无需逐节执行。 ![图片](https://lf3-static.bytednsdoc.com/obj/eden-cn/809eh7uhkbd/feilian/vpn-domain-20261012/flow.svg) 根据故障的影响范围，选择相应的对比方法和检查方向。 |影响范围 |对比方法与检查方向 | |---|---| |更换网络后仍无法访问 |从其他网络及目标站点侧验证，检查目标服务或其出口。多个网络均失败是检查线索，不能单独确定根因。 | |仅连接云 VPN 后异常 |在终端执行 cURL，根据失败阶段检查 DNS、访问策略和转发路径。 | |仅个别终端异常 |对比正常终端的版本、DNS 代理、系统代理、安全软件及网络过滤器。 | |间歇失败或时快时慢 |记录发生时间，结合路径探测、链路质量和双端抓包对比。 | 确定异常环节后，每次只验证相关调整，并重新测试同一域名。访问恢复后记录测试时间和结果；仍异常时保留命令输出、配置、日志和抓包供进一步分析。 ### 1. 确认故障对象按以下步骤区分主页面和依赖资源的访问问题。 1. 对比正常与异常终端，确认问题是否只在连接云 VPN 后出现，以及是所有用户受影响还是仅部分用户异常。 2. 确认访问失败的域名和端口。主页面无法打开时，从浏览器地址栏确认目标地址；主页面能打开但部分功能异常时，打开开发者工具的 **Network（网络）** 面板，刷新页面并查找失败请求的域名。一个页面可能同时访问 API、脚本、图片、视频和 CDN 等多个域名。 3. 选择一个可重复出现问题的域名和端口。后续在终端、浏览器和 CPE 上测试同一个对象，记录每次结果及时间。 ### 2. 使用 cURL 测试在故障终端上使用 cURL 查看解析、连接、握手和 HTTP 响应。Ping 使用 ICMP，不携带 HTTP Host 或 TLS SNI，因此不能代替域名访问测试。根据下面的操作获取完整输出，再选择排查方向。在出现问题的终端上按以下步骤测试。示例中的域名和端口均需替换为实际值。 1. 执行请求并保留完整输出。 ```shell curl -Iv https://<故障域名>:<端口> ``` HTTP 网站使用 `http://`。命令参数说明如下。 |参数 |作用 | |---|---| |`-I` |发送 HEAD 请求，只获取响应头。部分服务对 HEAD 和浏览器使用的 GET 请求处理不同；必要时去掉 `-I`，或复制浏览器实际失败请求进行对比。 | |`-v` |输出解析、连接、握手和请求响应等详细信息。 | |`-k` |跳过证书校验。仅用于与正常校验结果做对比；使用该参数后请求成功，不代表证书有效。 | 2. 根据输出判断失败阶段。未解析出地址时，检查 DNS；出现 `Trying` 后连接失败时，检查 TCP；出现 `Connected to` 后握手失败时，检查 TLS 和访问权限；收到 HTTP 响应后，继续检查状态码和业务结果。 3. 证书校验失败时，可追加 `-k` 做一次对比测试。 ```shell curl -Ikv https://<故障域名>:<端口> ``` 该操作用于判断跳过证书校验后请求能否继续，不应作为证书问题的修复方式。以下请求示例展示了解析、TCP 连接、TLS 握手和 HTTP 响应各阶段的输出。示例使用了跳过证书校验的 `-k` 参数，仅用于识别日志阶段；检查证书时应去掉该参数。地址、时间和证书信息以实际输出为准。 ```bash root@macos ~ # curl -Ikv https://www.baidu.com # 1、DNS 解析阶段 * Host www.baidu.com:443 was resolved. * IPv6: (none) * IPv4: 30.100.0.9, 30.100.0.10, 30.100.0.11, 30.100.0.12 # 2、TCP 连接阶段 * Trying 30.100.0.9:443... * Connected to www.baidu.com (30.100.0.9) port 443 * ALPN: curl offers h2,http/1.1 # 3、TLS 握手阶段 * (304) (OUT), TLS handshake, Client hello (1): * (304) (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 / [blank] / UNDEF * ALPN: server accepted http/1.1 # 4、TLS 证书验证阶段 * Server certificate: * subject: C=CN; ST=Beijing; L=Beijing; O=Beijing Baidu Netcom Science Technology Co., Ltd.; CN=baidu.com * start date: Jul 9 02:32:55 2026 GMT * expire date: Jan 24 02:32:55 2027 GMT * issuer: C=BE; O=GlobalSign nv-sa; CN=GlobalSign RSA OV SSL CA 2018 * SSL certificate verify ok. # 5、ALPN 协议协商阶段 * using HTTP/1.x > HEAD / HTTP/1.1 # 6、HTTP 请求阶段 > Host: www.baidu.com > User-Agent: curl/8.7.1 > Accept: */* > * Request completely sent off # 7、HTTP 响应阶段 < HTTP/1.1 200 OK HTTP/1.1 200 OK < Cache-Control: private, no-cache, no-store, proxy-revalidate, no-transform < Content-Length: 0 < Content-Type: text/html < Pragma: no-cache < Server: bfe < Date: Thu, 24 Sep 2026 11:13:40 GMT < # 8、HTTP 连接保持阶段 * Connection #0 to host www.baidu.com left intact ``` ### 3. 选择排查方向根据同一次请求的完整输出，选择下表中的对应章节来排查具体问题。超时可能发生在不同阶段，不能只根据退出码判断；每次调整后，重新测试同一业务地址，确认结果是否变化。 |请求结果 |排查章节 | |---|---| |无法解析域名、解析超时或地址不符合预期 |[域名解析异常](https://docs.volcengine.com/docs/6427/2733245#.5Z-f5ZCN6Kej5p6Q5byC5bi4) | |已解析出地址，但 TCP 连接失败 |[TCP 连接失败](https://docs.volcengine.com/docs/6427/2733245#.dGNwLei_nuaOpeWksei0pQ==) | |TCP 已连接，在 TLS 握手期间失败 |[TLS 握手失败](https://docs.volcengine.com/docs/6427/2733245#.dGxzLeaPoeaJi-Wksei0pQ==) | |证书校验失败，或收到异常 HTTP 响应 |[证书校验或 HTTP 响应异常](https://docs.volcengine.com/docs/6427/2733245#.6K-B5Lmm5qCh6aqM5oiWLWh0dHAt5ZON5bqU5byC5bi4) | |cURL 请求符合预期，但浏览器仍异常 |[cURL 正常，但网页访问异常](https://docs.volcengine.com/docs/6427/2733245#.Y3VybC3mraPluLjvvIzkvYbnvZHpobXorr_pl67lvILluLg=) | ## 域名解析异常当 cURL 无法解析域名，或解析地址与资源选路配置不一致时，先检查终端使用的 DNS，再根据结果检查中心 DNS 和下车 CPE。解析出地址只表示获得了 DNS 答复，还需核对地址是否符合预期。例如，某域名按选路配置应返回 `30.100.x.x` 调度地址，却返回了公网 IP，就需要检查资源匹配和解析路径。 ### 判断解析结果在故障终端执行 `nslookup <故障域名>`，记录 DNS 服务器、响应状态和返回地址。下面为经过本地 DNS 代理的输出示例。 ```bash root@macos ~ # nslookup www.baidu.com Server: 127.0.0.1 Address: 127.0.0.1#53 Name: www.baidu.com Address: 30.100.0.24 Name: www.baidu.com Address: 30.100.0.25 ``` 根据解析现象选择检查方向。 |解析现象 |检查方向 | |---|---| |请求超时 |检查本地 DNS 代理是否监听、请求是否发出、响应是否返回，再检查物理网络及中心 DNS 的可达性。 | |NXDOMAIN、SERVFAIL 或无所需记录 |记录具体响应状态。NXDOMAIN 表示查询的域名不存在，SERVFAIL 表示服务器无法完成查询；没有所需记录也不等于 NXDOMAIN。核对域名、上游 DNS 和 CPE 日志，不据此直接认定 gRPC 故障。 | |返回非预期地址 |核对域名资源、员工选路策略，以及系统或浏览器是否绕过飞连 DNS 代理。 | |返回预期地址 |继续检查 TCP 连接和访问权限。 | ### 检查终端 DNS 代理云 VPN 连接后，本地 DNS 代理监听 `127.0.0.1:53`。请求进入代理后，通过 Bloom Filter 匹配域名规则；命中云 VPN 域名规则的请求发往中心 DNS，未命中的请求使用物理网络 DNS。下图展示该解析路径。 ![图片](https://lf3-static.bytednsdoc.com/obj/eden-cn/809eh7uhkbd/topic-docs/feilian/borders-20261021/101b05e93a17d25b.png) ```text 应用 DNS 请求 → 本地 DNS Proxy（127.0.0.1:53） → 命中云 VPN 域名规则：发送至中心 DNS → 未命中规则：使用物理网络 DNS ``` 常见异常的检查方式如下。是否存在第三方 VPN 冲突，应通过端口、请求路径和停用前后的结果确认。 |常见异常 |可能原因 |验证与处理 | |---|---|---| |`127.0.0.1:53` 未监听 |DNS Proxy 未启动、启动失败或端口冲突。 |检查端口占用和飞连日志；关闭冲突程序后重连云 VPN。 | |端口正常，但请求未进入代理 |系统 DNS 顺序、系统代理、第三方 VPN 或网络过滤组件改变了请求路径。 |核对系统 DNS/代理设置，停用第三方网络组件后复测。 | |浏览器与 nslookup 结果不一致 |浏览器启用了 DoH、私密 DNS 或独立代理。 |临时关闭安全 DNS/DoH 和浏览器代理，再用同一域名复测。 | |卸载第三方 VPN 后仍异常 |驱动、过滤器或服务残留。 |检查并完整清理残留网络组件，重启终端后复测。 | 以 macOS 为例，按以下步骤检查终端环境。调整代理或安全软件前记录原设置，测试后恢复不需要变更的配置。 1. 检查系统 DNS 配置。 ```shell scutil --dns ``` 查看解析器配置中是否包含 `127.0.0.1`，并与 `nslookup` 的实际查询结果对照。 ![图片](https://lf3-static.bytednsdoc.com/obj/eden-cn/809eh7uhkbd/topic-docs/feilian/borders-20261021/7055961e995bb90c.png) 2. 检查 53 端口及占用进程。 ```shell sudo lsof -i udp:53 sudo ps -fp ``` 将 `` 替换为上一条命令显示的进程号，确认是否为 `corplink-service`。如由其他程序占用，核实冲突后再处理并重连云 VPN。 ![图片](https://lf3-static.bytednsdoc.com/obj/eden-cn/809eh7uhkbd/topic-docs/feilian/borders-20261021/2086676a8af666cd.png) 3. 检查系统代理及第三方 VPN。在当前网络连接的代理设置中，核对 HTTP、HTTPS、SOCKS 和自动代理配置。临时停用相关代理后，用同一域名复测；系统版本不同，设置入口可能不同。 ```Plain Text ![操作示意](https://lf3-static.bytednsdoc.com/obj/eden-cn/809eh7uhkbd/topic-docs/feilian/borders-20261021/fd9b096198fe8cfb.png =600x) ``` ```Plain Text ![操作示意](https://lf3-static.bytednsdoc.com/obj/eden-cn/809eh7uhkbd/topic-docs/feilian/borders-20261021/3723a5c238ec2b2f.png =600x) ``` macOS 可在当前网络的详细信息中检查代理设置，在 iCloud 设置中检查专用代理，并在系统设置中搜索防火墙和网络过滤器。不同 macOS 版本的菜单位置可能不同。若 `dig`、`traceroute`、`nslookup` 和 `curl` 使用的解析路径或结果不一致，可临时关闭 iCloud 专用代理（Private Relay），对同一域名重新执行查询和访问测试，比较关闭前后的结果。测试后恢复不需要变更的设置。有关专用代理的说明，参见 [Apple 官方说明](https://www.apple.com/sg/privacy/docs/iCloud_Private_Relay_Overview_Dec2021.PDF)。 4. 检查网络过滤器和防火墙。核对第三方安全软件的过滤规则和拦截记录。需要停用组件做对比时，限定测试时间并在测试后恢复；不要仅凭安装记录判断冲突。卸载第三方 VPN 后仍异常时，检查其驱动、服务或过滤器是否残留。 ```Plain Text ![操作示意](https://lf3-static.bytednsdoc.com/obj/eden-cn/809eh7uhkbd/topic-docs/feilian/borders-20261021/cc0c61b4aec124c9.png =600x) ``` ```Plain Text ![操作示意](https://lf3-static.bytednsdoc.com/obj/eden-cn/809eh7uhkbd/topic-docs/feilian/borders-20261021/4f6bde998dae0ec4.png =600x) ``` ### 检查解析超时本地 DNS 代理工作正常但查询仍超时时，抓包确认发往中心 DNS 的请求和响应。完全无响应可能与请求路径、回程路径或服务端状态有关，需要结合报文判断。终端经物理网卡访问中心 DNS 时，也可能受到运营商或跨地域网络波动影响。中心 DNS 查询即使失败，也可能返回 `NXDOMAIN` 或 `SERVFAIL` 等响应；应区分“收到错误响应”和“完全未收到响应”。在使用北京公网中心 DNS 的部署中，海外终端直达该地址的路径可能受到跨境链路影响，可对比经国内 CPE 转发后的结果。 ![图片](https://lf3-static.bytednsdoc.com/obj/eden-cn/809eh7uhkbd/topic-docs/feilian/borders-20261021/f9406f46ad2f8993.png) 如果已确认终端直达中心 DNS 的路径异常，且企业在国内部署了可用的 CPE，可通过员工选路策略让相关流量经 CPE 转发。按以下步骤先对受影响用户验证。 1. 添加中心 DNS 的 IP 资源。国内租户主要使用两个中心 DNS：`180.184.33.35`（旧租户）和 `180.184.34.245`（新租户）。不确定当前租户使用哪个中心 DNS 时，可将两个 IP 全部加入 IP 资源。 ![图片](https://lf3-static.bytednsdoc.com/obj/eden-cn/809eh7uhkbd/topic-docs/feilian/borders-20261021/545f4aa0a56f33b6.png) 2. 将 IP 资源加入员工选路策略，指定国内 CPE 下车点。先将生效对象限定为受影响用户，确认该 CPE 能访问中心 DNS 后再扩大范围。 ![图片](https://lf3-static.bytednsdoc.com/obj/eden-cn/809eh7uhkbd/topic-docs/feilian/borders-20261021/13bfef0318e26502.png) 3. 重新执行域名解析和 cURL 测试。可结合 `traceroute` 观察中心 DNS 地址的路径变化，并通过抓包确认流量经过预期 CPE。路径探测无响应不能单独作为失败依据，最终以解析和业务访问结果验证。 ### 检查 CPE 解析和日志终端已收到 DNS 响应但没有预期记录时，核对域名拼写和实际下车 CPE，再检查 CPE 的上游 DNS 与调度日志。内网域名需要使用能够解析该域名的 DNS 服务器。 ![图片](https://lf3-static.bytednsdoc.com/obj/eden-cn/809eh7uhkbd/topic-docs/feilian/borders-20261021/254139b494916743.png) 在实际下车 CPE 上按以下步骤操作。 1. 执行健康检查。 ```bash cd /opt/feilian/cpe/bin/ ./feilian-cpe-health-check ``` 检查输出中以下项目是否成功。 * 网络测试连接中心 DNS gRPC `sdwan-rpc.feilian.cn:49920`； * 业务应用连接中心 DNS gRPC `sdwan-rpc.feilian.cn:49920`； * 中心 DNS UDP 端口可达； * 主备 POP、主备隧道状态正常。 ![图片](https://lf3-static.bytednsdoc.com/obj/eden-cn/809eh7uhkbd/topic-docs/feilian/borders-20261021/f98ce956290a4d3a.png) 2. 检查 DNS 配置并在 CPE 本地测试解析。查看 `/etc/resolv.conf` 中的 `nameserver`。以下为配置示例。 ```bash root@node:~# cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 100.96.0.2 nameserver 100.96.0.3 options rotate nameserver 1.1.1.1 ``` 执行 `nslookup <故障域名>`，验证 CPE 本地能否解析该域名。以下为解析成功的输出示例。 ```bash root@node:~# nslookup www.baidu.com Server: 100.96.0.2 Address: 100.96.0.2#53 Non-authoritative answer: www.baidu.com canonical name = ps_other.a.shifen.com. Name: ps_other.a.shifen.com Address: 61.135.162.87 ``` 如果无法解析，为 CPE 配置能够解析该域名的 DNS 服务器，然后再次执行 `nslookup <故障域名>`，确认返回预期地址。 3. 查看同一时间、同一域名的事件日志。在 `cpe.event.log` 中过滤域名及 `dns_grpc` 记录，对照请求和回复。将命令中的域名替换为故障域名。 ```bash tail -f /opt/feilian/cpe/log/cpe.event.log | grep '<故障域名>' # 或过滤 dns_grpc 模块并查找指定域名 cat /opt/feilian/cpe/log/cpe.event.log | grep dns_grpc | grep -i www.baidu.com {"client_ip":"-","level":"INFO","module":"dns_grpc","msg":" dispatchRequest requestID: 73e7626e-b457-4bea-84da-c36c3bc8cc72, action: 1001, req: \rwww.baidu.com","path":"service/grpc/conn_receive.go:57","pid":"-","request_id":"-","time":"2026-09-28T11:10:15.032+08:00","uid":"-"} {"client_ip":"-","level":"INFO","module":"dns_grpc","msg":" dispatcher send reply msg: requestID:\"73e7626e-b457-4bea-84da-c36c3bc8cc72\" action:1001 data:\"\\n\\x00\\x12\\rwww.baidu.com\\x1a\\x0e169.254.128.33\\\"\\x0e182.61.200.108\\\"\\x0e182.61.200.110\"","path":"service/grpc/conn_receive.go:160","pid":"-","request_id":"-","time":"2026-09-28T11:10:15.033+08:00","uid":"-"} ``` |日志结果 |说明 |排查方向 | |---|---|---| |未出现对应域名请求 |请求可能未到达该 CPE，或被调度到其他下车点。 |检查中心 DNS 链路、资源匹配和实际下车 CPE。 | |出现请求但未返回结果 |CPE 侧解析或上游 DNS 异常。 |检查 `/etc/resolv.conf`、上游 DNS 可达性和解析权限。 | |请求与回复均正常 |CPE DNS 处理基本正常。 |回到终端检查响应是否返回，以及后续访问链路是否成功。 | ## TCP 连接失败 cURL 已解析出地址，但在 `Trying` 后连接失败或超时时，检查访问策略、CPE 转发及目标服务端口。退出码 `7` 表示连接失败，不一定是主动拒绝；退出码 `28` 还需结合日志确认发生在哪个阶段。下面为连接阶段超时的输出示例。 ```bash user@macos ~ % curl -Ikv https://www.baidu.com * Host www.baidu.com:443 was resolved. * IPv6: (none) * IPv4: 30.200.0.58, 30.200.0.59, 30.200.0.60, 30.200.0.61 * Trying 30.200.0.58:443... * connect to 30.200.0.58 port 443 from 192.168.13.245 port 57284 failed: Operation timed out * Trying 30.200.0.59:443... * connect to 30.200.0.59 port 443 from 192.168.13.245 port 57361 failed: Operation timed out * Trying 30.200.0.60:443... * connect to 30.200.0.60 port 443 from 192.168.13.245 port 57412 failed: Operation timed out * Trying 30.200.0.61:443... * connect to 30.200.0.61 port 443 from 192.168.13.245 port 57468 failed: Operation timed out * Failed to connect to www.baidu.com port 443 after 300011 ms: Couldn't connect to server * Closing connection curl: (28) Failed to connect to www.baidu.com port 443 after 300011 ms: Couldn't connect to server ``` 按以下步骤核对连接路径。按以下步骤核对本场景的访问策略、CPE 转发配置和报文。 1. 核对目标 IP 的访问权限。在飞连管理后台的 **零信任接入 \> VPN 策略 \> 访问权限** 中，检查目标用户实际匹配的策略。优先级数值越大越先匹配；相同优先级下，最近修改的策略优先。高优先级的 IP 拒绝策略可能覆盖域名放行策略。详细说明参见[管理 VPN 访问权限](https://help.feilian.cn/help-center/manage-vpn-access-permissions)。 2. 探测路径，并在下车 CPE 上对比目标访问结果。 macOS 可按目标 TCP 端口执行以下路径探测。 ```bash root@macos ~ # sudo traceroute -P TCP -p 443 -w 1 www.baidu.com traceroute to www.baidu.com (30.200.0.85), 64 hops max, 40 byte packets 1 * * * 2 * * * 3 * * * ... 10 * * * ``` 若路径探测全程显示 `* * *`，表示未收到探测响应。核对目标用户的访问策略，并与该用户可正常访问的其他域名做对比。若能看到下车 CPE 的隧道地址，则继续检查 CPE 到目标站点的连通性，并结合抓包确认实际业务报文是否经过 CPE。在实际下车 CPE 上对同一域名和端口执行 cURL 测试，并与终端结果对比。若 CPE 也无法连接，继续检查 CPE 到目标服务的链路和端口；若 CPE 可以连接而终端失败，继续检查访问策略和 CPE 转发路径。 3. 检查 CPE 转发配置。以下命令用于读取配置，先结合路由和报文确认异常，再调整配置。 |命令 |检查内容 | |---|---| |`iptables -L FORWARD -n` |核对 FORWARD 链默认策略及规则是否允许目标流量，是否命中 DROP。默认策略为 DROP 时，也应继续检查是否存在有效的允许规则。 | |`sysctl net.ipv4.ip_forward` |确认 IPv4 转发开启（值为 `1`）。 | |`sysctl net.ipv4.conf.all.rp_filter` |检查反向路径校验。严格模式 `1` 可能影响非对称路由；需结合接口配置和路由核对，不能仅凭该值认定故障。`0` 为关闭，`2` 为宽松模式。 | 4. 在终端和实际下车 CPE 同时抓包，并复现连接失败。两端开始抓包后，在故障终端对同一域名和端口重新执行 cURL 请求，记录测试时间。请求结束后停止抓包，保存两端的抓包文件。对照请求时间、目标地址和端口，检查 `SYN` 是否到达 CPE 并向目标发出，以及 `SYN-ACK` 是否返回 CPE 和终端。请求从 CPE 发出但没有回包时，检查目标服务、CPE 后的防火墙、ACL 和返回路由；CPE 已收到回包而终端未收到时，检查 CPE 返回终端的转发路径。 ### 对照 CPE 四个方向的报文已确认相应 ICMP 流量被允许时，可使用 Ping 配合 CPE 抓包辅助检查转发路径。这只能验证所测试的 ICMP 流量，不能替代 HTTP/HTTPS 域名策略验证。较大报文也可用于观察 MTU 和分片相关现象。按以下步骤采集报文。先确认报文已从终端发出，再比较 CPE 各接口，避免把本地发送失败误判为隧道故障。 1. 在终端发送测试报文。以下以 `2000` 字节载荷为例。 Linux 的 `-M do` 和 Windows 的 `-f` 禁止分片；若载荷超过接口 MTU，报文可能在本地就无法发出，应减小载荷后重试。 macOS 示例允许分片，三种命令的结果不能直接等同。 ```shell # macOS（默认会自动分片） ping -s 2000 <目标> # Linux（-M do 禁止分片，可同时探测 PMTU） ping -s 2000 -M do <目标> # Windows ping -l 2000 -f <目标> ``` 2. 在 CPE 同步抓取 ICMP 报文。 ```shell # 筛选报文长度大于 1000 字节的 ICMP 报文 sudo tcpdump -i any 'icmp and len>1000' -eevvnn ``` 该过滤器会忽略较短报文。减小测试载荷或检查分片、ICMP 错误响应时，应相应调整过滤条件，避免漏包。 3. 对照四个观察点并保存结果。 ```shell sudo tcpdump -i any 'icmp and len>1000' -v -w /tmp/icmp.pcap ``` 抓取足够的复现报文后按 `Ctrl+C` 停止，抓包文件保存在 `/tmp/icmp.pcap`。下图以 `tun0_master` 和 `eth0` 为例展示转发方向；实际网卡名称和源地址转换行为以设备配置为准。 ![图片](https://lf3-static.bytednsdoc.com/obj/eden-cn/809eh7uhkbd/feilian/vpn-domain-20261012/path.svg) 确认接口、目标地址、抓包过滤条件和前一观察点后，按下表检查。未看到报文表示需要继续查证，不能直接作为丢包原因。 |方向与位置 |报文源地址 → 目的地址 |看到报文的含义 |未看到报文时的检查方向 | |---|---|---|---| |① 正向进入：CPE 隧道口 tun0_master |终端虚拟 IP → 真实目标 IP |该测试报文已到达 CPE 隧道入口。 |确认终端已发出报文、实际选路经过该 CPE，核对隧道状态和客户端策略。 | |② 正向发出：CPE 物理口 eth0 |物理口 IP（SNAT 后）→ 真实目标 IP |该报文已从物理接口发出；存在 SNAT 时，可核对转换后的源地址。 |前一观察点有报文时，检查 FORWARD 链、ip_forward、rp_filter、策略路由及 SNAT。 | |③ 反向进入：CPE 物理口 eth0 |真实目标 IP → 物理口 IP |目标回复已返回 CPE 物理接口。 |确认请求已发出，检查 CPE 后续链路、目标服务、防火墙、ACL 及返回路由。 | |④ 反向发出：CPE 隧道口 tun0_master |真实目标 IP → 终端虚拟 IP |回包已进入返回终端的隧道路径，继续核对终端是否收到。 |物理口已有回包时，检查反向路由、连接跟踪状态及 rp_filter 等过滤规则。 | ## TLS 握手失败 cURL 出现 `Connected to` 后，若在 `Client hello` 之后超时或报错，需检查 TLS 协商及域名访问权限。TCP 连接成功不代表握手和后续传输一定成功。下面为 ClientHello 发出后超时的输出示例，单凭此输出无法判断是否由访问策略造成。 ```bash root@macos ~ # curl -Iv --max-time 5 https://blocked.example.com:443 * Host blocked.example.com:443 was resolved. * IPv4: 10.20.30.40 * Trying 10.20.30.40:443... * Connected to blocked.example.com (10.20.30.40) port 443 # TCP 连接已建立 * ALPN: curl offers h2,http/1.1 * (304) (OUT), TLS handshake, Client hello (1): # ← 发出 ClientHello 后无 ServerHello，等待超时 * Operation timed out after 5000 milliseconds with 0 bytes received * Closing connection curl: (28) Operation timed out ``` 常见握手现象及检查方向如下。 |输出特征 |检查方向 | |---|---| |ClientHello 后 `Operation timed out` |核对域名访问权限，检查服务端和路径中的设备是否收到并回复握手报文。 | |`Connection reset by peer` |通过终端与 CPE 对比测试、抓包确认连接重置位置；不能仅凭 RST 认定来源。 | |`wrong version number` 或 `alert handshake failure` |确认端口提供 HTTPS 服务，核对 TLS 版本及密码套件。可追加 `--tls-max 1.2` 做兼容性对比，但不应将降级当作默认修复。 | |`curl: (35)` |查看完整 TLS 错误和此前连接日志；必要时结合抓包确认失败阶段。 | 在下车 CPE 上对同一域名和端口执行相同的 cURL 请求，对照终端的握手结果。两侧均失败时，继续检查目标服务及共同经过的路径；仅终端失败时，结合访问权限和双端抓包检查终端到 CPE 的路径。应同时核对两侧解析地址、代理设置和 TLS 环境。在管理后台按以下步骤检查权限配置。 1. 进入 **零信任接入 \> VPN 策略 \> 访问权限**，使用 **可访问检测**。选择域名类型，填写目标用户对象和故障域名后执行检测，核对匹配策略。可访问检测仅检查静态配置匹配，不产生真实业务流量；检测通过后，仍需在终端执行 cURL、DNS 查询或抓包验证实际访问结果。 ![图片](https://lf3-static.bytednsdoc.com/obj/eden-cn/809eh7uhkbd/topic-docs/feilian/borders-20261021/e16bc8da034ed083.png) 2. 检查策略的生效节点和对象。未指定生效节点时，通常表示策略适用于全部相关节点；指定节点时，确认包含实际使用的云 VPN 节点。核对目标用户、资源、动作和优先级。 ![图片](https://lf3-static.bytednsdoc.com/obj/eden-cn/809eh7uhkbd/topic-docs/feilian/borders-20261021/077fad1f14ca1be3.png) 3. 修改后在故障终端重新访问同一域名，并保存 cURL 结果。 HTTP 域名识别通常依据 Host，HTTPS 通常依据 TLS ClientHello 中的 SNI。 ICMP 和不携带域名信息的 TCP/UDP 请求需按实际协议选择资源配置，不能用 Ping 结果代替域名权限验证。 ## 证书校验或 HTTP 响应异常此分支包含证书校验失败和 HTTP 响应异常两类情况。前者应检查证书及本地信任配置；后者表示已收到 HTTP 响应，需要结合状态码、请求内容和响应来源继续判断。按实际报错选择下面对应部分。 ### 证书校验失败使用不带 `-k` 的 `curl -Iv` 保留错误。在下车 CPE 上执行相同请求，对比域名解析、证书、代理及本地 CA 配置。两侧结果不同只能缩小检查范围，不能直接认定发生了证书替换。下面分别为证书域名不匹配和证书过期的输出示例。核对报错中的域名、有效期和证书链，再检查服务端证书配置或终端信任库。 ```bash * Host wrong.example.com:443 was resolved. * IPv4: 1.2.3.4 * Trying 1.2.3.4:443... * Connected to wrong.example.com (1.2.3.4) port 443 * (304) (OUT), TLS handshake, Client hello (1): * (304) (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * Server certificate: * subject: CN=www.other-site.com # 证书域名与访问域名不一致 * start date: ... * expire date: ... * issuer: ... * SSL certificate problem: certificate subject name does not match wrong.example.com * Closing connection curl: (60) SSL certificate problem: certificate subject name does not match ``` ```bash * Host internal.example.com:443 was resolved. * IPv4: 10.1.2.3 * Trying 10.1.2.3:443... * Connected to internal.example.com (10.1.2.3) port 443 * (304) (OUT), TLS handshake, Client hello (1): * (304) (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * Server certificate: * subject: CN=internal.example.com * start date: Jan 1 00:00:00 2020 GMT * expire date: Dec 31 23:59:59 2023 GMT # 证书已过期 * issuer: CN=Internal CA # 自签名或私有 CA * SSL certificate problem: certificate has expired * Closing connection curl: (60) SSL certificate problem: certificate has expired ``` ### HTTP 响应异常如果请求已收到 HTTP 响应，但状态码或业务结果异常，先检查请求方法、URL、鉴权信息及响应头，再到目标应用、代理或网关日志中查找对应请求。HEAD 与浏览器实际请求可能不同，应使用相同请求进行对比。下面为返回 HTTP 502 的示例。此状态码不能单独证明故障发生在目标应用，也不能排除代理到上游之间的连接问题。 ```bash * Host app.example.com:443 was resolved. * IPv4: 30.100.0.9 * Trying 30.100.0.9:443... * Connected to app.example.com (30.100.0.9) port 443 * TLS handshake completed * Server certificate: * subject: CN=app.example.com * SSL certificate verify ok. > HEAD / HTTP/1.1 # TLS 已通过，请求已发出 > Host: app.example.com > User-Agent: curl/8.7.1 > < HTTP/1.1 502 Bad Gateway # 服务端返回错误状态码 < Server: nginx < Content-Type: text/html < * Connection #0 to host app.example.com left intact ``` 根据错误信息检查对应配置。HTTP 4xx/5xx 可能由目标应用、网关或代理返回，应先确认响应来源。 |现象 |检查方向 | |---|---| |证书域名不匹配 |核对访问域名、解析地址、服务端证书和 SNI 配置，并检查是否使用了代理。 | |证书过期或自签名证书 |核对证书有效期、终端时间、信任链及本地 CA。私有 CA 不受信任并不等于证书被替换。 | |HTTP 4xx/5xx |核对请求方法、路径、鉴权及响应头，在应用或网关日志中查找对应请求。HEAD 与 GET 结果不一致时，复测浏览器实际请求。 | ## cURL 正常，但网页访问异常主域名的 cURL 请求成功，但浏览器仍打不开或页面不完整时，继续检查失败资源及浏览器请求。主域名可访问并不代表页面依赖的 API、脚本、图片或 CDN 均可访问。在出现问题的浏览器和同一终端上按以下步骤对比。 1. 查找失败资源并核对域名选路。打开开发者工具的 **Network（网络）** 面板，刷新页面，查找失败、长时间 Pending 或超时的请求。核对这些域名是否属于预期的资源调度范围。 ![图片](https://lf3-static.bytednsdoc.com/obj/eden-cn/809eh7uhkbd/topic-docs/feilian/borders-20261021/ff92ca848ff05b1e.png) 2. 对比浏览器代理和安全 DNS 设置。临时关闭相关代理插件或安全 DNS（DoH）后复测，观察结果是否变化。请求路径可能因此变化，但不能只凭设置已启用判断原因；测试后恢复不需要变更的设置。 ![图片](https://lf3-static.bytednsdoc.com/obj/eden-cn/809eh7uhkbd/topic-docs/feilian/borders-20261021/4e8c678fa8b031e5.png) 3. 查看异常请求的 **Timing（计时）** 。各阶段耗时可提供以下线索，需结合具体请求和链路指标判断。 * **Initial Connection / SSL**：检查 TCP 建连和 TLS 握手耗时。 * **TTFB**：同时受请求传输、网络往返及服务器处理时间影响。 * **Content Download**：结合响应大小、带宽、丢包及服务端发送情况检查下载耗时。 ![图片](https://lf3-static.bytednsdoc.com/obj/eden-cn/809eh7uhkbd/topic-docs/feilian/borders-20261021/6b5e028af1ae74d7.png) 4. 复制异常请求到终端测试。在 **Network** 中右键单击请求，选择 **Copy \> Copy as cURL**；使用 PowerShell 时选择对应的 **Copy as PowerShell** 格式。在匹配的终端中执行，比较相同 URL、方法和请求头下的结果与耗时。 ![图片](https://lf3-static.bytednsdoc.com/obj/eden-cn/809eh7uhkbd/topic-docs/feilian/borders-20261021/6720728f5032a1a8.png) ![图片](https://lf3-static.bytednsdoc.com/obj/eden-cn/809eh7uhkbd/topic-docs/feilian/borders-20261021/170b1e9d4ced1d93.png) 5. 核对 CPE 网络质量和带宽用量。在管理控制台查看故障时间附近的带宽、时延及丢包变化，确认是否存在带宽打满或链路波动。需要进一步测试吞吐时，参见[云 VPN 上传与下载速率慢排障案例](https://help.feilian.cn/help-center/cloud-vpn-upload-and-download-speed-slow-troubleshooting-case)。 ```Plain Text ![操作示意](https://lf3-static.bytednsdoc.com/obj/eden-cn/809eh7uhkbd/topic-docs/feilian/borders-20261021/deb1cefd5f3c5ace.png =600x) ``` ```Plain Text ![操作示意](https://lf3-static.bytednsdoc.com/obj/eden-cn/809eh7uhkbd/topic-docs/feilian/borders-20261021/ac52300badb04381.png =600x) ``` 如果链路时延、丢包率和 CPE 带宽用量均未发现明显异常，但页面仍加载缓慢，可联系应用管理员，结合失败请求和耗时结果继续检查站点资源加载策略及服务端性能。 ## 移动端访问异常移动端出现同类问题时，先排除客户端版本和 DNS 路径差异。应用可能动态访问多个域名和 IP，仅配置一个主域名不一定覆盖全部请求。按以下步骤逐项验证，每次调整后重新连接并测试同一业务。 1. 更新飞连客户端。 iOS 和 HarmonyOS 用户通过对应应用商店检查更新；Android 应用市场版本可能不同，可通过[飞连客户端下载指南](https://docs.volcengine.com/docs/Feilian/SealSuiteClientDownloadGuide?lang=zh)获取安装包。 2. 对比系统和浏览器的 DNS 设置。临时关闭专用 DNS、私密 DNS 或安全 DNS 后测试。这些设置可能使用不同的加密 DNS 协议并改变解析路径，不能一概称为 DoH。以下分别为系统和浏览器设置示例。 ![图片](https://lf3-static.bytednsdoc.com/obj/eden-cn/809eh7uhkbd/topic-docs/feilian/borders-20261021/bb8011b9f41a671f.png) ![图片](https://lf3-static.bytednsdoc.com/obj/eden-cn/809eh7uhkbd/topic-docs/feilian/borders-20261021/f90f96d754cb41a9.png) 3. 必要时由管理员扩大选路范围进行小范围验证。当应用依赖域名难以完整收集时，可评估使用 `0.0.0.0/1` 和 `128.0.0.0/1` 覆盖 IPv4 地址空间，再配置对应选路策略。这不覆盖 IPv6，实际转发仍需核对策略匹配结果。全流量引流会扩大 CPE 出口、带宽和跨地域链路的影响范围；若 CPE 位于海外，国内业务也可能绕行海外，增加访问延迟。先对少量用户验证访问效果和带宽用量，再评估是否扩大生效范围。 ```Plain Text ![操作示意](https://lf3-static.bytednsdoc.com/obj/eden-cn/809eh7uhkbd/topic-docs/feilian/borders-20261021/69b3a13a55028ec2.png =600x) ``` ```Plain Text ![操作示意](https://lf3-static.bytednsdoc.com/obj/eden-cn/809eh7uhkbd/topic-docs/feilian/borders-20261021/8f126d856bbeec51.png =600x) ``` ## 验证排查结果完成对应分支的处理后，使用同一故障域名和端口复测，确认解析、请求和实际页面访问结果。 1. 重新验证域名解析和业务访问。执行 `nslookup` 和 cURL 测试，再在浏览器中访问原业务地址。确认域名可稳定访问，DNS 解析地址符合预期，cURL 与浏览器的访问结果一致；页面依赖资源存在异常时，同时复测这些资源。 2. 记录调整内容和复测结果。保留测试时间、调整的配置及调整前后的结果，说明问题是否恢复。 3. 问题仍未解决时，整理排查信息供进一步分析。按以下清单汇总本次已执行的检查及其结果。 * 故障域名、端口、发生时间、复现方式及受影响用户范围。 * 终端系统、飞连客户端版本、连接节点及实际下车 CPE。 * DNS 查询结果、完整 cURL 输出，以及浏览器失败请求和报错。 * 相关资源配置、员工选路策略和访问权限匹配结果。 * CPE 健康检查结果、对应时间的事件日志，以及终端和 CPE 的抓包文件。 ## 附录：cURL 错误码常见退出码及后续检查方向如下。不同版本的 cURL 可能使用不同的错误文字，应同时查看完整输出。 |错误码 |含义 |对应故障阶段与排查方向 | |---|---|---| |`curl: (0)` |Success |命令执行成功；仍需核对 HTTP 状态码和实际业务结果。 | |`curl: (5)` |Could not resolve proxy |代理地址解析失败——检查终端系统代理配置、PAC 脚本或代理服务器本身是否可达。 | |`curl: (6)` |Couldn't resolve host |DNS 解析失败——检查终端 DNS Proxy、中心 DNS 链路。 | |`curl: (7)` |Failed to connect |建立连接失败，可能是连接被拒、端口不可达或代理连接失败；结合详细日志检查。 | |`curl: (16)` |HTTP/2 error |HTTP/2 帧层错误——尝试加 \-\-http1.1 降级测试，排除中间设备不兼容 HTTP/2。 | |`curl: (22)` |HTTP page not retrieved (\-\-fail) |启用 \-\-fail 等失败检测选项时，HTTP 错误响应可导致此退出码；检查响应来源、请求与应用日志。 | |`curl: (28)` |Connection timed out |连接或数据传输超时——目标端口不可达、链路被阻断或对端无响应。 | |`curl: (35)` |SSL connect error |TLS 握手失败——检查域名策略是否放行、SNI 是否识别、中间设备是否干扰握手。 | |`curl: (47)` |Too many redirects |跟随重定向时达到次数上限——通常是重定向环路，检查目标站点配置。 | |`curl: (51)` |SSL certificate problem |证书或对端身份校验失败；检查域名匹配、信任链、有效期及代理配置。 | |`curl: (52)` |Empty reply from server |TCP 已连接但服务端未返回任何数据——服务端异常、连接被中间设备静默断开。 | |`curl: (55)` |Failed sending network data |发送数据失败；结合日志检查连接中断、链路和中间设备。 | |`curl: (56)` |Failure receiving network data |接收响应数据失败——连接被重置（RST）、对端异常断开或中间设备干预。 | |`curl: (58)` |Problem with the local certificate |本地客户端证书问题——双向 TLS 场景下客户端证书未正确配置或过期。 | |`curl: (60)` |Peer certificate cannot be authenticated |服务端证书链不被信任——检查本地信任库及证书链，并在 CPE 侧对比验证。 | |`curl: (77)` |Problem reading the SSL CA cert |本地 CA 证书库读取失败——检查证书文件路径、权限或系统 CA 包是否损坏。 | |`curl: (92)` |Stream error in HTTP/2 framing layer |HTTP/2 流错误——尝试 \-\-http1.1 降级，排查中间代理对 HTTP/2 的兼容性。 | |`curl: (96)` |QUIC connection error |HTTP/3/QUIC 连接失败——UDP 被阻断或 QUIC 不被支持，尝试强制 TCP/HTTP2。 | |`curl: (97)` |Proxy handshake error |代理握手失败——HTTP/SOCKS 代理配置错误或代理本身异常。 | |`curl: (98)` |Client certificate required |服务端要求客户端证书（双向 TLS）——检查客户端证书是否正确导入和选择。 | 完整错误码列表（0–100+）请参考官方文档：[curl man page — Exit Codes](https://curl.se/docs/manpage.html#EXITCODES)。