最近遇到一个很有代表性的网络问题：
同一台电脑上，
https://www.google.com/可以正常打开，但https://www.flextv.cc/无法访问。
看到这种现象，很多人的第一反应是"FlexTV 网站挂了"。但"某个网站打不开"只是表象，真正的故障可能发生在 DNS、TCP、TLS、HTTP、CDN、代理，甚至浏览器扩展中的任何一层。
这篇文章记录一次完整的定位过程：如何通过 curl、nslookup 和 --resolve 建立证据链，证明问题发生在 DNS 解析阶段，并给出 Windows、macOS 和路由器端的解决方法。
一、先说结论
本次排查得到的结论是：
当前网络使用的 DNS 服务器
192.168.8.1无法及时解析www.flextv.cc；改用1.1.1.1或8.8.8.8后可以正常获得 CDN 地址。绕过默认 DNS、直接连接 CDN 后，FlexTV 返回HTTP 200。
因此，本次故障发生在当前网络的 DNS 解析链路，而不是 FlexTV 首页服务或 HTTPS 证书整体不可用。
这里特意使用"当前网络的 DNS 解析链路异常"，而不是直接说"运营商屏蔽"或"路由器 Bug"。客户端测试可以定位故障层级，但仅凭这些证据，还不能唯一确定路由器内部究竟是缓存异常、上游 DNS 故障、过滤规则，还是转发程序问题。
二、打开一个 HTTPS 网站时，系统做了什么
浏览器访问下面这个地址：
text
https://www.flextv.cc/通常要经过以下步骤：
- DNS 解析 ：把
www.flextv.cc转换成一个或多个 IP 地址。 - TCP 连接：连接目标 IP 的 443 端口。
- TLS 握手：协商加密连接，并校验服务器证书。
- HTTP 请求：发送请求，服务器或 CDN 返回状态码和内容。
- 浏览器渲染：加载 HTML、CSS、JavaScript、图片和接口数据。
这几个步骤存在明确的先后关系：如果 DNS 没有返回 IP，客户端就不知道该连接哪台服务器，后面的 TCP 和 TLS 自然无法开始。
因此，排查时最重要的事情不是反复刷新浏览器，而是先回答一个问题：请求到底失败在哪一层？
三、第一步：用 curl 对比两个网站
在 Windows PowerShell 中执行：
powershell
curl.exe -I -sS -L --max-redirs 5 --connect-timeout 10 --max-time 20 https://www.flextv.cc/
curl.exe -I -sS -L --max-redirs 5 --connect-timeout 10 --max-time 20 https://www.google.com/FlexTV 的关键输出是：
text
curl: (28) Resolving timed out after 10008 millisecondsGoogle 则正常返回：
text
HTTP/1.1 200 OKResolving timed out 说明了什么
这里最关键的词是 Resolving。
它表示 curl 在等待域名解析结果时超时，还没有取得 www.flextv.cc 对应的 IP 地址。所以本次请求尚未进入 TCP 连接阶段，也没有开始 TLS 证书校验。
不同错误通常对应不同的故障层：
| 错误表现 | 更可能的故障层 |
|---|---|
Resolving timed out |
DNS 解析 |
Could not resolve host |
DNS 解析 |
Failed to connect |
TCP、路由或防火墙 |
Connection refused |
端口未监听或被主动拒绝 |
certificate problem |
TLS 或证书 |
HTTP 403/404/500 |
已到达 HTTP/应用层 |
Google 能返回 200 说明同一台电脑具备基本联网能力，但这并不能单独证明 FlexTV 是 DNS 问题。接下来还需要直接查询 DNS。
四、第二步：对比默认 DNS 和公共 DNS
先使用系统当前配置的 DNS：
powershell
nslookup www.flextv.cc
nslookup flextv.cc
nslookup www.google.com本次环境的默认 DNS 是：
text
Server: UnKnown
Address: 192.168.8.1查询 www.flextv.cc 时出现超时：
text
DNS request timed out但查询 www.google.com 可以返回多个地址，说明这个 DNS 并不是完全不可用，而是对特定域名或特定解析链路出现了问题。
接下来跳过默认 DNS，直接查询 Google DNS 和 Cloudflare DNS：
powershell
nslookup www.flextv.cc 8.8.8.8
nslookup www.flextv.cc 1.1.1.1两者都能返回结果，关键内容类似：
text
Name: www.flextv.cc.queniuaa.com
Aliases: www.flextv.cc
Addresses: 多个 CDN 边缘 IP这一步说明：
www.flextv.cc的公共 DNS 记录存在；- 域名通过 CNAME 指向 CDN；
- 公共递归 DNS 可以继续解析 CNAME 并返回多个边缘节点 IP；
- 当前默认 DNS
192.168.8.1没有及时完成同样的解析。
为什么 flextv.cc 和 www.flextv.cc 的结果不同
排查中还发现：默认 DNS 能解析根域名 flextv.cc，但解析 www.flextv.cc 超时。
这是完全可能的，因为它们是两条不同的 DNS 记录：
text
flextv.cc
www.flextv.cc根域名可能直接使用 A 记录，而 www 子域名可能使用 CNAME 接入 CDN。能够解析根域名，并不代表一定能够正确处理 www 的 CNAME 链。
五、第三步：绕过 DNS 验证 HTTPS 和网站服务
现在已经知道公共 DNS 能返回 CDN IP，但还需要回答另一个问题：
即使 DNS 有问题，FlexTV 的 HTTPS 服务本身是否正常？
可以使用 curl 的 --resolve 参数，为单次请求临时指定域名和 IP 的对应关系：
powershell
curl.exe -I -sS --connect-timeout 10 --max-time 20 `
--resolve www.flextv.cc:443:43.109.161.39 `
https://www.flextv.cc/在 macOS 或 Linux 中，可以写成一行：
bash
curl -I -sS --connect-timeout 10 --max-time 20 --resolve www.flextv.cc:443:43.109.161.39 https://www.flextv.cc/本次返回：
text
HTTP/1.1 200 OK
Server: Tengine
Content-Type: text/html;charset=utf-8为什么 --resolve 的证据很重要
--resolve 只为这一次 curl 请求提供临时映射，不会修改系统 hosts 文件。
虽然连接使用了指定 IP，但请求 URL 仍是 https://www.flextv.cc/，因此：
- HTTP
Host仍然是www.flextv.cc； - TLS SNI 仍然携带
www.flextv.cc； - curl 仍会按照
www.flextv.cc校验证书。
最终返回 HTTP 200，说明在这个测试节点上，TCP、TLS、CDN 和 HTTP 首页服务都能工作。
至此证据链完整了：
- 默认访问 FlexTV：DNS 解析超时；
- 默认访问 Google：返回 HTTP 200；
- 默认 DNS 查询 FlexTV：超时；
- 两个公共 DNS 查询 FlexTV：均成功；
- 绕过默认 DNS：FlexTV 返回 HTTP 200。
所以，问题可以定位到当前 DNS 解析链路。
注意：上面的 CDN IP 是本次排查时的临时结果，后续可能变化。不要把它长期写入 hosts 文件。
六、确认 Windows 当前使用的 DNS
在 PowerShell 中执行：
powershell
Get-DnsClientServerAddress -AddressFamily IPv4 |
Where-Object { $_.ServerAddresses.Count -gt 0 } |
Format-Table -AutoSize InterfaceAlias,InterfaceIndex,ServerAddresses本次输出为：
text
InterfaceAlias InterfaceIndex ServerAddresses
以太网 8 {192.168.8.1}192.168.8.1 是局域网私有地址，通常代表路由器。电脑把查询交给路由器后，由路由器的 DNS 代理继续向上游服务器查询。
因此，"默认 DNS 是路由器"并不意味着真正出问题的一定是路由器硬件，还可能是：
- 路由器 DNS 转发程序异常；
- 路由器缓存了错误或不完整的记录；
- 路由器配置的上游 DNS 异常；
- 家长控制、广告拦截或安全策略匹配了域名；
- VPN、代理或安全软件接管了 DNS；
- CNAME 链在某一层被错误处理。
七、Windows 解决方法
方法一：通过图形界面修改
- 打开"设置"→"网络和 Internet"。
- 进入当前使用的"以太网"或"Wi-Fi"。
- 找到 DNS 服务器分配，点击"编辑"。
- 选择手动 IPv4。
- 首选 DNS 设置为
1.1.1.1。 - 备用 DNS 设置为
8.8.8.8。 - 保存后关闭并重新打开浏览器。
方法二：使用管理员 PowerShell
先查看接口名称：
powershell
Get-DnsClientServerAddress -AddressFamily IPv4假设接口名为"以太网"，执行：
powershell
Set-DnsClientServerAddress `
-InterfaceAlias "以太网" `
-ServerAddresses "1.1.1.1","8.8.8.8"如果使用 Wi-Fi，需要把接口名改成实际名称，例如：
powershell
Set-DnsClientServerAddress `
-InterfaceAlias "Wi-Fi" `
-ServerAddresses "1.1.1.1","8.8.8.8"然后清除 DNS 缓存：
powershell
Clear-DnsClientCache也可以使用传统命令：
cmd
ipconfig /flushdnsWindows 回滚为自动 DNS
如果需要重新使用 DHCP 或路由器下发的 DNS：
powershell
Set-DnsClientServerAddress `
-InterfaceAlias "以太网" `
-ResetServerAddresses
Clear-DnsClientCache八、macOS 解决方法
方法一：通过系统设置修改
- 打开"系统设置"→"网络"。
- 选择当前使用的 Wi-Fi，点击"详细信息"。
- 进入"DNS"。
- 添加
1.1.1.1和8.8.8.8。 - 保存并重新打开浏览器。
旧版本 macOS 的入口可能是"系统偏好设置"→"网络"→"高级"→"DNS"。
方法二：使用终端
先查看所有网络服务：
bash
networksetup -listallnetworkservices如果当前服务名是 Wi-Fi，执行：
bash
sudo networksetup -setdnsservers "Wi-Fi" 1.1.1.1 8.8.8.8刷新 DNS 缓存：
bash
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder如果使用网线，服务名可能是 Ethernet、USB 10/100/1000 LAN 或其他名称，需要按 networksetup -listallnetworkservices 的实际输出替换。
macOS 回滚为自动 DNS
bash
sudo networksetup -setdnsservers "Wi-Fi" Empty
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder其中 Empty 表示清除手动 DNS，恢复使用网络自动下发的配置。
九、多台设备都失败时，应该修改路由器
如果同一 Wi-Fi 下的 Windows、Mac、手机都无法访问 FlexTV，逐台修改 DNS 只能治标，更合理的做法是修复路由器。
进入路由器后台，在 WAN、Internet、DHCP 或 DNS 页面中设置：
text
首选 DNS：1.1.1.1
备用 DNS：8.8.8.8保存后根据路由器说明重新连接 WAN 或重启路由器，然后让终端设备重新连接网络。
如果是公司网络，不建议自行绕过内部 DNS。企业 DNS 可能承担内部域名解析、审计和访问控制，应把 nslookup 与 curl 输出提供给网络管理员处理。
十、修改 DNS 后如何验证
不要只看浏览器是否"偶尔能打开"。建议分层验证。
1. 验证 DNS
Windows：
powershell
nslookup www.flextv.ccmacOS：
bash
nslookup www.flextv.cc
dig www.flextv.cc期望看到 CNAME 或 IP，而不是 DNS request timed out。
2. 验证 HTTPS
Windows：
powershell
curl.exe -I -sS --connect-timeout 10 --max-time 20 https://www.flextv.cc/macOS：
bash
curl -I -sS --connect-timeout 10 --max-time 20 https://www.flextv.cc/返回 200 最理想。返回 301 或 302 也说明 DNS、TCP 和 TLS 已经成功，应继续检查重定向目标。
有些网站不支持 HEAD 请求，可能对 curl -I 返回 405 Method Not Allowed。这时可以使用普通 GET，只丢弃响应正文：
Windows：
powershell
curl.exe -sS -o NUL -w "%{http_code}`n" https://www.flextv.cc/macOS：
bash
curl -sS -o /dev/null -w '%{http_code}\n' https://www.flextv.cc/3. 验证浏览器
- 完全关闭浏览器后重新打开；
- 使用无痕窗口测试；
- 检查安全 DNS（DoH）配置；
- 暂时断开 VPN 或代理进行对比；
- 检查扩展、内容过滤器和安全软件；
- 确认页面图片、样式和接口也能正常加载。
十一、如果仍然打不开，按结果继续分层
| 检测结果 | 可能原因 | 下一步 |
|---|---|---|
| 公共 DNS 也无法解析 | 权威 DNS、域名状态或到公共 DNS 的网络异常 | 换网络，查询权威 DNS 和域名注册状态 |
| DNS 正常，但 443 连接超时 | 路由、防火墙、CDN 节点或服务器不可达 | curl -v、换网络、检查防火墙 |
| TCP 成功，但 TLS 失败 | 证书、SNI、系统时间或中间人代理 | 检查系统时间、证书链和 HTTPS 代理 |
| curl 正常，浏览器失败 | 浏览器缓存、扩展、DoH、代理或 HSTS | 无痕模式、关闭扩展、检查浏览器策略 |
| 只有公司网络失败 | 企业 DNS、网关或安全产品策略 | 联系管理员并提交命令输出 |
| 只有一台设备失败 | 单机 DNS、代理、hosts 或安全软件 | 对比其他设备和网络接口配置 |
还可以检查 hosts 文件中是否存在旧映射。
Windows：
powershell
Get-Content C:\Windows\System32\drivers\etc\hosts |
Select-String -Pattern "flextv"macOS：
bash
grep -i "flextv" /etc/hosts这里只建议检查相关条目，不要在不了解用途的情况下删除其他 hosts 配置。
十二、本文所有执行命令的逐条解析
前面的正文更关注排查思路，这一节把实际出现过的命令逐条拆开说明。为了避免误操作，先按性质分为两类：
- 只读诊断命令 ：
curl、nslookup、dig、Get-DnsClientServerAddress、Get-Content、grep。它们只读取或发起测试请求，不会修改 DNS 配置。 - 配置修改命令 ：
Set-DnsClientServerAddress、networksetup -setdnsservers。它们会改变网络接口的 DNS，需要管理员权限，并应提前了解回滚方法。
1. 两条 curl 对比探测命令
powershell
curl.exe -I -sS -L --max-redirs 5 --connect-timeout 10 --max-time 20 https://www.flextv.cc/
curl.exe -I -sS -L --max-redirs 5 --connect-timeout 10 --max-time 20 https://www.google.com/两条命令只有 URL 不同，目的是在同一台电脑、同一网络、相同参数下进行对照实验。
| 组成部分 | 含义 |
|---|---|
curl.exe |
明确调用 Windows 上的原生 curl 程序。写出 .exe 可以避免某些旧版 PowerShell 把 curl 当成其他命令别名。 |
-I |
只请求响应头，通常发送 HTTP HEAD 请求，不下载完整网页正文。适合快速检查状态码、重定向和服务器响应。 |
-s |
Silent，隐藏进度条等常规输出。 |
-S |
Show error。与 -s 同时使用时，仍显示错误信息，因此组合写成 -sS。 |
-L |
自动跟随 301、302、307、308 等重定向。 |
--max-redirs 5 |
最多跟随 5 次重定向，防止错误配置导致无限循环。 |
--connect-timeout 10 |
连接阶段最多等待 10 秒。该阶段通常包含 DNS 解析、TCP 建连以及建立安全连接所需的前置过程，所以本次 DNS 超时大约在 10 秒后被终止。 |
--max-time 20 |
限制整个 curl 操作最多运行 20 秒，包括连接和数据传输。 |
https://.../ |
要测试的完整 URL。使用 HTTPS 表示目标端口通常为 443，并需要进行 TLS 握手。 |
第一条命令测试 FlexTV，第二条测试 Google。Google 返回 200，而 FlexTV 输出 Resolving timed out，所以差异出现在目标域名的解析路径，而不是所有网络请求都失败。
2. 使用默认 DNS 查询三个域名
powershell
nslookup www.flextv.cc
nslookup flextv.cc
nslookup www.google.comnslookup 的基本语法是：
text
nslookup 要查询的域名 [指定的DNS服务器]当末尾没有指定 DNS 服务器时，它会使用当前系统配置的默认 DNS。本次环境中就是 192.168.8.1。
三条命令分别承担不同作用：
| 命令 | 为什么执行 |
|---|---|
nslookup www.flextv.cc |
查询实际打不开的 www 子域名，确认默认 DNS 是否能返回 CNAME 或 IP。 |
nslookup flextv.cc |
查询根域名，与 www 子域名对比，判断是否只有某一条 DNS 记录或 CNAME 链异常。 |
nslookup www.google.com |
使用相同默认 DNS 查询一个已知可访问域名，验证默认 DNS 是否完全失效。 |
nslookup 输出中的常见字段含义：
| 输出 | 含义 |
|---|---|
Server / Address |
实际接收本次查询的 DNS 服务器名称和地址。 |
Name |
最终解析到的规范名称。 |
Aliases |
查询名称是别名，即 CNAME。 |
Addresses |
返回的 IPv4 或 IPv6 地址。 |
Non-authoritative answer |
答案来自递归 DNS 的查询或缓存，而不是直接由权威 DNS 服务器返回；通常不是错误。 |
DNS request timed out |
DNS 服务器在等待时间内没有返回有效答复。它说明查询链路超时，但不能仅凭这一行断定是路由器、上游 DNS 还是过滤策略。 |
3. 指定公共 DNS 服务器查询
powershell
nslookup www.flextv.cc 8.8.8.8
nslookup www.flextv.cc 1.1.1.1这两条命令中的第二个参数指定"把问题交给哪台 DNS 服务器回答"：
8.8.8.8是 Google Public DNS；1.1.1.1是 Cloudflare 公共 DNS。
指定服务器后，nslookup 不再使用系统默认的 192.168.8.1。两台独立公共 DNS 都能返回结果，可以降低"单个公共 DNS 恰好缓存了特殊结果"的可能性。
这些命令只改变本次查询的目标服务器，不会修改 Windows 或 macOS 的永久 DNS 配置。
4. 使用 curl --resolve 临时绕过 DNS
Windows PowerShell 写法：
powershell
curl.exe -I -sS --connect-timeout 10 --max-time 20 `
--resolve www.flextv.cc:443:43.109.161.39 `
https://www.flextv.cc/macOS/Linux 写法：
bash
curl -I -sS --connect-timeout 10 --max-time 20 --resolve www.flextv.cc:443:43.109.161.39 https://www.flextv.cc/新增部分的含义如下：
| 组成部分 | 含义 |
|---|---|
| PowerShell 行尾的反引号 ````` | PowerShell 的续行符，表示下一行仍属于同一条命令。反引号后不要再放空格。也可以把整条命令写在一行。 |
--resolve |
为单次 curl 请求提供临时的"域名:端口:IP"映射，不修改系统 DNS 和 hosts 文件。 |
www.flextv.cc |
保留真实请求域名，用于 HTTP Host、TLS SNI 和证书校验。 |
443 |
此临时映射适用的目标端口；443 是 HTTPS 默认端口。 |
43.109.161.39 |
本次公共 DNS 返回的一个 CDN 边缘 IP，只是当时的测试样本。 |
| 最后的 HTTPS URL | curl 仍按这个 URL 发起请求并校验证书，而不是直接访问 https://IP/。 |
如果该命令返回 HTTP 200，说明指定节点上的 DNS 后续链路------TCP、TLS、HTTP------能够工作。它不能证明所有地区的每个 CDN 节点都正常，但足以说明"默认 DNS 失败"是本次客户端故障的重要原因。
5. 查看 Windows 网络接口的 DNS 配置
完整命令：
powershell
Get-DnsClientServerAddress -AddressFamily IPv4 |
Where-Object { $_.ServerAddresses.Count -gt 0 } |
Format-Table -AutoSize InterfaceAlias,InterfaceIndex,ServerAddresses这是一条 PowerShell 管道命令，应从左向右理解：
| 组成部分 | 含义 |
|---|---|
Get-DnsClientServerAddress |
读取本机各网络接口的 DNS 客户端配置，不会修改配置。 |
-AddressFamily IPv4 |
只显示 IPv4 DNS 地址，避免 IPv6 结果干扰本次观察。 |
| ` | ` |
Where-Object { ... } |
按花括号中的条件过滤对象。 |
$_ |
当前正在经过管道的那一个网络接口对象。 |
$_.ServerAddresses |
读取当前接口的 DNS 服务器地址集合。 |
.Count |
取得该集合中的地址数量。 |
-gt 0 |
Greater than 0，即只保留至少配置了一个 DNS 地址的接口。 |
Format-Table |
把最终对象格式化成表格，方便人阅读。 |
-AutoSize |
根据内容自动计算控制台列宽。 |
InterfaceAlias |
网络接口显示名称，例如"以太网"或"Wi-Fi"。 |
InterfaceIndex |
Windows 分配给网络接口的数字索引。 |
ServerAddresses |
该接口当前使用的 DNS 服务器列表。 |
正文中还使用了简化命令：
powershell
Get-DnsClientServerAddress -AddressFamily IPv4它不进行过滤和表格字段选择，会列出所有 IPv4 网络接口，主要用于在修改配置前确认正确的 InterfaceAlias。
6. 在 Windows 中设置 DNS
以"以太网"为例：
powershell
Set-DnsClientServerAddress `
-InterfaceAlias "以太网" `
-ServerAddresses "1.1.1.1","8.8.8.8"以 Wi-Fi 为例：
powershell
Set-DnsClientServerAddress `
-InterfaceAlias "Wi-Fi" `
-ServerAddresses "1.1.1.1","8.8.8.8"| 组成部分 | 含义 |
|---|---|
Set-DnsClientServerAddress |
修改指定网络接口的 DNS 客户端配置。通常需要管理员 PowerShell。 |
-InterfaceAlias |
按接口显示名称选择要修改的网络接口。名称必须和查询结果完全一致。 |
"以太网" / "Wi-Fi" |
示例接口名称；带引号可以安全处理名称中的空格或非 ASCII 字符。 |
-ServerAddresses |
指定要写入的 DNS 服务器地址集合。 |
"1.1.1.1","8.8.8.8" |
PowerShell 使用逗号构造两个元素的数组。系统通常优先使用第一个，在需要时尝试第二个。 |
这是会修改系统配置的命令。如果接口名称写错，命令通常会报找不到接口；如果公共 DNS 在当前网络被限制，修改后可能导致其他域名也无法解析，因此必须保留下面的回滚命令。
7. 清理 Windows DNS 缓存
PowerShell 命令：
powershell
Clear-DnsClientCache传统命令：
cmd
ipconfig /flushdns两条命令都用于清除 Windows DNS 客户端的本地缓存，使后续访问重新查询 DNS。
Clear-DnsClientCache是 PowerShell 的 DNS 客户端命令；ipconfig是 Windows 网络配置工具；/flushdns是ipconfig的"清空 DNS 缓存"参数。
它们不会修改 DNS 服务器地址，也不会清除浏览器自己的全部缓存。通常执行其中一条即可，正文同时列出是为了兼容不同操作习惯。
8. Windows 回滚为自动 DNS
powershell
Set-DnsClientServerAddress `
-InterfaceAlias "以太网" `
-ResetServerAddresses
Clear-DnsClientCache-ResetServerAddresses 与 -ServerAddresses 的作用相反：它删除该接口的手动 DNS 设置，让 Windows 重新使用 DHCP 或系统默认方式获得 DNS。第二条命令随后清理旧缓存，避免回滚后继续使用之前的解析结果。
如果实际接口是 Wi-Fi，同样要替换 -InterfaceAlias 的值。
9. 列出 macOS 网络服务
bash
networksetup -listallnetworkservices| 组成部分 | 含义 |
|---|---|
networksetup |
macOS 自带的网络配置命令行工具。 |
-listallnetworkservices |
列出系统中所有网络服务名称，例如 Wi-Fi、Ethernet。 |
这是一条只读命令。后续设置 DNS 时使用的是"网络服务名称"，所以应先执行它，而不是猜测接口名称。
10. 在 macOS 中设置 DNS
bash
sudo networksetup -setdnsservers "Wi-Fi" 1.1.1.1 8.8.8.8| 组成部分 | 含义 |
|---|---|
sudo |
以管理员权限运行后面的命令，终端可能要求输入当前管理员密码；输入密码时不会显示字符。 |
networksetup |
macOS 网络配置工具。 |
-setdnsservers |
为指定网络服务写入 DNS 服务器列表。 |
"Wi-Fi" |
要修改的网络服务名称。使用网线时应替换为实际名称。 |
1.1.1.1 8.8.8.8 |
按顺序设置的两个 DNS 地址。Bash 使用空格分隔参数，不使用 PowerShell 的逗号数组写法。 |
这条命令会修改 Wi-Fi 服务的 DNS 配置，需要使用后面的 Empty 命令回滚。
11. 刷新 macOS DNS 缓存
bash
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder第一条命令：
dscacheutil是 macOS 目录服务缓存工具；-flushcache请求清空相关缓存，其中包括 DNS 解析缓存；sudo用管理员权限执行。
第二条命令：
killall按进程名称发送信号；-HUP表示发送 Hang Up 信号，通知服务重新加载；mDNSResponder是 macOS 负责 DNS/mDNS 解析的重要系统服务。
这里并不是永久"杀掉"DNS 服务。系统会让 mDNSResponder 继续运行或自动恢复，目的是促使缓存和解析状态刷新。两条命令通常没有成功提示，返回终端提示符不代表没有执行。
12. macOS 回滚为自动 DNS
bash
sudo networksetup -setdnsservers "Wi-Fi" Empty
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponderEmpty 是 networksetup 在这里使用的特殊值，表示删除该网络服务的手动 DNS 列表，恢复使用 DHCP 等自动配置。后两条命令负责刷新缓存和解析服务状态。
13. 使用 nslookup 和 dig 做修复后验证
bash
nslookup www.flextv.cc
dig www.flextv.ccnslookup www.flextv.cc使用当前默认 DNS 做简洁查询，适合快速确认是否仍然超时；dig www.flextv.cc会显示更完整的 DNS 报文信息，包括状态、记录类型、TTL、应答服务器和查询耗时；- 两条命令都没有指定 DNS 服务器，所以验证的是修改后的系统默认解析路径。
如果想让 dig 直接查询某台 DNS，可以使用：
bash
dig @1.1.1.1 www.flextv.cc其中 @1.1.1.1 表示把查询直接发送给 1.1.1.1。这是补充用法，不会修改系统 DNS。
14. 使用 curl 验证 HTTPS
Windows：
powershell
curl.exe -I -sS --connect-timeout 10 --max-time 20 https://www.flextv.cc/macOS：
bash
curl -I -sS --connect-timeout 10 --max-time 20 https://www.flextv.cc/参数含义与第 1 小节相同。这里没有 --resolve，所以 curl 会使用刚刚修改后的系统 DNS。其目的不是重复测试网页内容，而是验证新的 DNS 路径是否能继续完成 TCP、TLS 和 HTTP。
如果返回 301 或 302，表示服务器要求重定向，但 DNS、TCP 和 TLS 通常已经成功。想自动跟随重定向，可以再加入 -L。
15. 使用 GET 请求只输出 HTTP 状态码
Windows：
powershell
curl.exe -sS -o NUL -w "%{http_code}`n" https://www.flextv.cc/macOS：
bash
curl -sS -o /dev/null -w '%{http_code}\n' https://www.flextv.cc/| 组成部分 | 含义 |
|---|---|
不使用 -I |
curl 发送普通 GET 请求，适合不支持 HEAD 的网站。 |
-o |
指定响应正文的输出位置。 |
NUL |
Windows 的空设备，写入其中的数据会被丢弃。 |
/dev/null |
macOS/Linux 的空设备，作用与 Windows 的 NUL 相同。 |
-w |
Write out，在请求结束后按指定格式输出信息。 |
%{http_code} |
curl 的输出变量，代表最终 HTTP 状态码。 |
| PowerShell 中的 ```n`` | PowerShell 字符串中的换行符。 |
Bash 单引号中的 \n |
由 curl 的 -w 格式解释为换行。 |
这两条命令仍会执行完整 GET 请求，只是把响应正文丢弃，最后仅显示类似 200、301 或 500 的状态码。
16. 检查 Windows hosts 文件
powershell
Get-Content C:\Windows\System32\drivers\etc\hosts |
Select-String -Pattern "flextv"| 组成部分 | 含义 |
|---|---|
Get-Content |
读取文本文件内容。这里读取 Windows hosts 文件，不修改文件。 |
| hosts 路径 | Windows 的静态域名映射文件路径。hosts 的优先级通常高于普通 DNS 查询。 |
| ` | ` |
Select-String |
在文本中搜索匹配内容，作用类似 grep。 |
-Pattern "flextv" |
只显示包含 flextv 的行；默认按正则表达式匹配。 |
如果没有任何输出，通常表示 hosts 中没有匹配条目。该命令是只读检查，不会删除其他配置。
17. 检查 macOS hosts 文件
bash
grep -i "flextv" /etc/hosts| 组成部分 | 含义 |
|---|---|
grep |
在文本文件中搜索匹配行。 |
-i |
忽略大小写，因此 FlexTV、FLEXTV 和 flextv 都能匹配。 |
"flextv" |
要搜索的字符串。 |
/etc/hosts |
macOS 的静态域名映射文件。 |
如果命令没有输出，表示没有找到相关行。它同样不会修改 hosts 文件。
18. 文中提到的 curl -v
异常分支中还提到了：
bash
curl -v https://www.flextv.cc/-v 是 verbose，输出详细连接过程，包括代理使用情况、DNS 后的目标地址、TCP 连接、TLS 握手、请求头和响应头。它非常适合继续区分 TCP、TLS 和 HTTP 故障，但输出可能包含 Cookie、Authorization 等敏感请求头，复制到公开工单或博客前应先脱敏。
十三、这次排查带来的几个经验
1. "另一个网站能打开"只能证明部分网络能力正常
Google 能打开，可以排除完全断网，但无法直接判断目标网站是 DNS、TCP、TLS 还是应用层故障。
2. 错误信息中的阶段名称非常重要
Resolving timed out 已经明确指出 curl 卡在 DNS 阶段。先读懂错误，再决定下一条命令，通常比盲目清缓存或重装浏览器更有效。
3. 使用不同 DNS 交叉验证
默认 DNS 超时，而 1.1.1.1 和 8.8.8.8 都成功，证据比只测试一个公共 DNS 更可靠。
4. --resolve 是区分 DNS 与 HTTPS 故障的利器
它可以临时绕过 DNS，同时保留正确的 Host、SNI 和证书校验，非常适合验证 CDN 和 HTTPS 服务。
5. 不要长期固定 CDN IP
CDN IP 会随时间、地区、运营商和负载变化。写入 hosts 可能短期有效，但会破坏动态调度，后续还可能再次故障。
总结
面对"网站打不开"时，可以使用下面这套通用思路：
- 用
curl判断失败发生在 DNS、连接、TLS 还是 HTTP； - 用
nslookup或dig对比默认 DNS 与公共 DNS； - 获得可信 IP 后，用
curl --resolve绕过 DNS 验证 HTTPS； - 根据证据修改电脑或路由器 DNS；
- 清理缓存，并从 DNS、HTTPS、浏览器三个层面重新验收；
- 保留回滚方案，不把临时 CDN IP 当成永久解决办法。
本次问题最终可以概括为一句话：
默认 DNS 无法正确解析
www.flextv.cc，公共 DNS 可以；绕过 DNS 后网站返回HTTP 200，因此应修复或替换当前 DNS 解析链路。
说明： 本文中的 DNS 响应和 CDN IP 来自 2026-08-17 的一次实际诊断。DNS/CDN 结果具有时效性，读者应以自己执行命令时的结果为准。