公司 WiFi 下无法访问个人 Cloudflare 网站：原因与解决方案

> 现象：连公司 WiFi 后打不开 https://quant.aohan.net，但开自己手机热点就能正常访问。 > 结论：服务器和 Cloudflare Tunnel 运行正常，问题出在公司网络的出口安全策略。

---

一、为什么会这样——企业网络的五道封锁线

企业网络（尤其是中大型公司、写字楼 WiFi）普遍部署了上网行为管理设备或下一代防火墙（NGFW）。你的 quant.aohan.net 大概率触发了其中一条或多条规则。

1. DNS 过滤（最可能的根因）

自检方法：

# 在公司 WiFi 下运行，看 DNS 能解析出来吗
nslookup quant.aohan.net

# 对比——如果返回的 IP 和你热点下的不同，或者干脆无返回，就是 DNS 层拦截
nslookup quant.aohan.net 8.8.8.8

2. SNI / TLS 握手拦截

即使 DNS 解析成功，TLS 握手仍可能被拦截：

• Cloudflare Tunnel 的流量走 HTTPS，TLS 握手的 SNI（Server Name Indication）字段 是明文的。
• 企业防火墙可以读取 SNI 中的 quant.aohan.net，然后查域名信誉库。
• 如果企业部署了 SSL 中间人解密（SSL Forward Proxy / SSL Interception），流量会被解密检查，quant.aohan.net 的证书如果不是企业 CA 签发，可能直接被 RESET。

3. 深度包检测（DPI）

高端企业防火墙（如 Palo Alto、Fortinet、深信服）使用 DPI 技术，不仅看域名，还分析：

• 流量特征：Cloudflare Tunnel 的 QUIC 流量在 UDP 7844 端口上有可识别的协议指纹
• 行为模式：长连接 + 持续小包 + 非标准端口 → 疑似隧道/代理 → 封禁
• Cloudflare IP 段：某些企业会直接将 Cloudflare 的 AS13335 IP 段整体列入"代理/匿名器"类别

4. QUIC 协议被封

Cloudflare Tunnel 默认使用 QUIC（HTTP/3 over UDP）协议：

• QUIC 走 UDP 7844 端口，而企业防火墙通常只放行 UDP 53（DNS）和 443（HTTP/3 标准端口）
• UDP 非标准端口上的长连接 = 企业防火墙眼中的高危特征
• 很多企业的上网行为管理设备会直接丢弃非 53/443 的 UDP 流量

5. IP 段 / AS 级封锁

有些企业安全策略会对 Cloudflare 的 IP 段（AS13335）做粗粒度封锁，理由是：

• Cloudflare 免费版共享 IP，同一个 IP 上可能有数万个域名，其中不乏恶意站点
• 企业安全团队一刀切：把共享 CDN IP 段列入"代理/规避审查"类别

---

二、诊断方法

在公司 WiFi 下逐层排查，定位到底卡在哪一层：

# 第 1 层：DNS 解析
nslookup quant.aohan.net
# 如果返回 "server can't find" 或返回错误 IP → DNS 层拦截

# 第 2 层：TCP 连接
curl -v --connect-timeout 5 https://quant.aohan.net 2>&1 | head -20
# 如果卡在 "Trying IP..." → TCP 443 端口被封
# 如果卡在 "SSL connection" → TLS SNI 被拦截
# 如果返回 403/blocked 页面 → 上层网关拦截

# 第 3 层：QUIC vs HTTP/2
curl -v --http2 --connect-timeout 5 https://quant.aohan.net 2>&1 | head -20
# 如果 HTTP/2 能通但 QUIC 不通 → QUIC 端口被封

# 第 4 层：测试 Cloudflare 是否被封
curl -v --connect-timeout 5 https://cloudflare.com 2>&1 | head -20
# 如果连 cloudflare.com 也打不开 → AS13335 段整体被封

# 第 5 层：ping 测试 ICMP
ping -c 3 quant.aohan.net
# ICMP 和 TCP/443 走不同路径，ping 通不代表网站通

---

三、解决方案（按推荐度排序）

方案 A：手机热点（当前方案 ✅）

你已经发现这是可行的。优点：零配置、最简单。缺点：耗流量、手机不能走远。

方案 B：修改 DNS 为公共加密 DNS（推荐 🔥）

如果只是 DNS 层拦截，这是最小改动方案：

macOS 设置：

系统设置 → 网络 → Wi-Fi → 详细信息 → DNS
删除所有现有 DNS 服务器，添加：
  1.1.1.1 (Cloudflare DNS)
  8.8.8.8 (Google DNS)

但这个方案有局限——如果企业防火墙强制劫持 DNS（把所有 UDP 53 请求重定向到企业 DNS），普通 DNS 修改无效。

更强方案：开启 DNS-over-HTTPS (DoH)： 浏览器层面开启 DoH，DNS 查询走 HTTPS 443 端口，与普通网页流量混在一起，企业防火墙难以区分和劫持。

• Chrome：设置 → 隐私和安全 → 安全 → 使用安全 DNS → 选择 Cloudflare (1.1.1.1)
• Safari：较新版本默认支持 DoH，但设置入口不显式

方案 C：强制 Cloudflare Tunnel 走 HTTP/2

如果你的问题出在 QUIC，可以配置 cloudflared 禁用 QUIC：

编辑 cloudflared 配置文件，添加：

protocol: http2

修改后重启 tunnel：

cloudflared tunnel restart aohan-quant

方案 D：使用 Cloudflare Warp（如果没被封）

Cloudflare 自家的 Warp（基于 WireGuard 的 VPN）：

• 走 UDP 2408/500/4500/1701 端口
• 免费版够用
• 但如果企业已经把 Cloudflare 全封了，这招无效

方案 E：添加独立 IP / 专用证书（长期方案）

如果你想让网站看起来更像"正规站点"：

• 购买独立 IP 的 Cloudflare 方案（Business/Enterprise 级别）
• 使用知名的 TLD（.com / .cn），避免个人化子域名风格
• 但成本较高，个人项目不划算

方案 F：传统 VPN

使用 WireGuard/OpenVPN 回家或连到外部 VPN 服务器。CNNIC 认可的个人用途 VPN 是合法的，但不建议在公司设备上安装未授权 VPN 客户端（可能违反公司 IT 政策）。

---

四、为什么热点可以但公司 WiFi 不行

简单说：公司 WiFi 出口经过了安全网关的层层过滤，手机热点直连运营商骨干网。 不是你的网站不稳定，是公司网络策略把它挡了。

---

五、关键结论

• 你的服务器和 Cloudflare Tunnel 运行正常——热点能访问就证明了这一点
• 问题几乎 100% 出在公司 WiFi 出口的上网行为管理/防火墙上
• DNS 过滤是最可能的根因（域名太新、太小众、被归入"未分类"）
• QUIC 协议被封和 Cloudflare IP 段被封是次要可能性
• 最简单的绕过方案就是用手机热点；次简单是改 DNS + 浏览器开启 DoH

---

六、相关技术背景

• Cloudflare Tunnel 架构：cloudflared → QUIC/HTTP2 → Cloudflare Edge → 用户
• 企业常用上网行为管理产品：深信服 AC、山石 SG、Palo Alto NGFW、Fortinet FortiGate、Cisco Umbrella、Zscaler、Netskope
• DNS 加密协议：DNS-over-HTTPS (DoH, RFC 8484)、DNS-over-TLS (DoT, RFC 7858)
• Cloudflare IP 段：AS13335，覆盖 104.16.0.0/12 等大段