同一个网站，外网手机流量能打开，可用连上公司WiFi就转圈。内网这种事我遇到过不下十次，用不因每次排查下来原因都不一样。什原

最直接的外网一种情况：DNS解析结果不同。外网用的可用DNS（比如运营商默认的或者8.8.8.8）把域名解析到了A记录，内网DNS服务器可能配置了不同的内网解析策略，甚至直接把某些域名解析到了127.0.0.1或者一个不可达的用不因内网IP。我见过一家公司，什原内网DNS把某云存储服务的外网域名指向了一台已经下架的旧服务器，外网访问完全正常，可用内网死活连不上。内网nslookup一敲，用不因两边结果一对比，什原问题立刻现形。

防火墙和ACL规则在作怪

企业内网出口通常有防火墙做应用层过滤。有些防火墙策略写得非常粗——比如禁止所有HTTPS流量去往特定IP段，或者只放行白名单域名。你访问的网站在白名单之外，外网能通是因为你走的是手机基站，根本不经过公司防火墙。内网一连，请求先被防火墙拦下来，浏览器只能显示连接超时。这种情况有个典型特征：ping域名可能通，但TCP 443端口就是连不上。telnet 域名 443一试便知。

代理配置也是个坑。很多公司内网强制走HTTP代理，而代理服务器本身可能对某些目标地址做了限制，或者代理配置里写死了只允许访问特定域名。外网环境没有代理，直连自然没问题。内网浏览器如果没配代理，或者配了错误的代理地址，表现就是“外网能用内网不能用”。我见过一个案例，代理服务器的PAC脚本里有一行规则写错了，把所有*.example.com的请求都转发到了一个已经宕机的上游代理，而外网用户根本不加载这个PAC脚本。

路由和NAT的隐形墙

内网IP地址段通常是10.x.x.x或192.168.x.x，这些私有地址在公网上不可路由。如果目标网站的服务端做了来源IP限制——比如只允许公网IP访问，或者对私有IP段直接返回403——那内网用户就会被拒之门外。更隐蔽的是NAT回流问题：内网用户访问公司自己托管在云上的服务，请求从内网发出，经过NAT设备后源IP变成了公网IP，但服务端可能配置了只接受特定内网IP的规则，导致请求被丢弃。外网用户访问同一个服务，源IP是另一个公网地址，反而通过了。

还有一种情况跟MTU有关。内网某些VPN隧道或PPPoE连接会把MTU值调低，而目标网站返回的数据包较大且设置了DF（Don't Fragment）标志。外网路径MTU正常，内网路径MTU较小，大包被丢弃，表现为“网页能打开但加载不全”或者“一直转圈”。ping -f -l逐步测试就能找到临界值。

浏览器和系统层面的差异

别忽略本机配置。内网电脑可能安装了安全客户端，比如EDR、DLP或者上网行为管理软件，这些软件会hook网络栈，对特定域名或IP做拦截。外网手机上没有这些软件，访问自然正常。另外，内网电脑的hosts文件可能被IT部门修改过，写入了错误的映射记录。C:\Windows\System32\drivers\etc\hosts打开看一眼，比什么诊断工具都快。

证书问题也值得一查。内网如果部署了SSL解密设备，浏览器看到的证书是防火墙重新签发的，而目标网站启用了HSTS或者证书固定（certificate pinning），浏览器就会拒绝连接。外网没有SSL解密，证书链完整，一切正常。

排查顺序建议从简到繁：先nslookup对比DNS，再telnet测端口，然后检查代理和hosts，最后抓包看TCP握手卡在哪一步。多数情况下，问题出在DNS或防火墙策略上，真正复杂的路由问题反而少见。