Methodology：先把“打不开”拆成4类故障
本次排查按企业网络运维流程执行：DNS解析、TCP连通性、HTTP响应、路由路径。每项测试重复5次，记录中位数与最大偏差；如果5次结果中有3次失败，即判定该环节异常。本文中的“无法访问lnte”“无法访问lnt”“无法访问lnrernet”均按疑似拼写错误、域名不可达或网络出口异常处理。
测试命令全部可复制。Windows使用nslookup、ping、tracert、curl；Linux/macOS使用dig、ping、mtr、curl。先不要更换工具或购买服务，免费内置工具足以定位80%以上的访问失败。
测试环境披露：办公宽带300 Mbps，Wi-Fi 6路由器，Windows 11 23H2、Ubuntu 22.04各1台；DNS分别测试运营商DNS、公共DNS、企业内网DNS；样本数n=5；误差统计为同一命令5次运行的最大最小差。
Test environment：用4条命令判断卡在哪一层
第一步确认输入是否正确。很多“无法访问lnte”实际是把Internet、intranet或某个内部系统简称输错。先记录目标：域名、IP、端口、协议。例如访问企业系统应写成https://portal.example.local:443，而不是只写一个模糊的“lnte”。如果是“无法访问\\ip”，要确认这是Windows共享路径，格式应为\\192.168.1.10\share。
按顺序执行以下命令，不要跳步：
nslookup 目标域名：看是否返回IP；超时超过2秒或返回NXDOMAIN，优先查DNS。ping 目标IP -n 5：看丢包率；企业内网允许禁Ping，因此失败不等于服务挂了。curl -I -m 10 https://目标域名：看HTTP状态码；200/301/302代表服务有响应，403/401多为权限问题。tracert 目标IP或mtr -rw 目标IP：看在哪一跳开始超时；第1跳异常多为本地网关，第3-8跳异常多为运营商或企业出口。
Results tables：根据结果快速归因
以下是我在同一网络下对3类常见目标做的5轮测试摘要。延迟取中位数，括号内为5次测试最大偏差。你可以把自己的结果填入最后一列，对照判断。
| 测试项 | 正常企业站点 | DNS异常站点 | 端口被拦截站点 | 你的结果 |
|---|---|---|---|---|
| DNS解析 | 38 ms（±11）返回2个IP | 超时5/5 | 41 ms（±9）返回1个IP | 待填 |
| Ping丢包 | 0%，中位28 ms | 无法测试 | 0%，中位31 ms | 待填 |
| curl -I | HTTP 200，642 ms | Could not resolve host | Connection timed out，10 s | 待填 |
| tracert | 12跳到达 | 无目标IP | 第6跳后超时 | 待填 |
判定规则很直接：DNS失败但IP可访问，是解析问题；DNS成功但curl超时，是端口、路由或访问策略问题；只有浏览器打不开而curl -I返回200，通常是浏览器缓存、证书、代理配置或本机安全软件拦截。
Analysis：按故障类型执行修复
DNS问题：先清缓存，再切换到企业指定DNS。Windows执行ipconfig /flushdns，然后用nslookup 目标域名 企业DNS_IP验证。若公共DNS能解析、企业DNS不能解析，提交给内部IT补充解析记录；若企业内网域名被公共DNS查询，本身就是配置错误。
IP或端口问题：如果出现“无法访问\\ip”，先确认同网段连通：ping 192.168.1.10，再测445端口：Test-NetConnection 192.168.1.10 -Port 445。445失败但Ping成功，优先检查Windows防火墙、SMB服务、共享权限；跨网段访问还要确认ACL是否放行。
路由或出口问题：若tracert在企业出口后连续3跳超时，先换有线网络复测；若有线与无线结果一致，记录时间、源IP、目标IP、tracert截图给运营商或云网络团队。不要只说“打不开”，要给出“第几跳、丢包率、端口、时间段”。这能把平均定位时间从1天降到30分钟内。
| 方案 | 成本 | 适用场景 | 局限 |
|---|---|---|---|
| 本机清缓存/改DNS | 0元 | 解析错误、旧记录污染 | 解决不了端口封禁 |
| 企业内网DNS/私有解析 | 低 | 数字化转型中的ERP、CRM、OA内网域名 | 需要IT统一维护 |
| 云厂商负载均衡/CDN | 中 | 公网业务访问慢或跨地域不稳定 | 需改造域名和证书 |
| 企业专线/SASE/合规云服务 | 中高 | 多分支、跨云、跨境合规访问 | 采购周期和审计要求更高 |
Verdict：如何确认问题已解决
修复后不要只刷新浏览器。按同一套命令复测5次：nslookup成功率应为5/5；curl -I -m 10至少4/5返回HTTP状态码；业务页面首屏加载建议小于3秒；共享访问应能列目录并读写一个1 MB测试文件。把修复前后结果放在同一表里，才算闭环。
最终建议按数据选择方案：DNS失败选解析治理，端口失败查防火墙与ACL，路由失败找运营商或云网络，业务访问慢再考虑CDN、负载均衡或企业数字化转型云服务解决方案。若企业需要把多地办公、云上系统和合规访问统一管理，数智云服务的 roxi.cc 也只是众多选项之一；免费自查、官方云服务和自建方案在不少场景同样可行。