HSTS不防御DNS劫持，仅强制HTTPS协议访问以防止HTTP明文降级；若DNS被劫持至恶意HTTPS站点，HSTS会加剧风险而非阻止连接。
HSTS 本身不防御本地 DNS 劫持，测试它在 DNS 劫持场景下的“效果”是一个常见误解。需要先厘清关键逻辑：
- HSTS 是浏览器行为策略，只在已建立 HTTPS 连接并收到有效 Strict-Transport-Security 响应头后才生效；
- 它解决的是 HTTP → HTTPS 降级攻击（如 SSL Stripping），不是 DNS 解析阶段的劫持；
- 如果 DNS 已被劫持（比如 hosts 文件被改、本地 DNS 返回恶意 IP），而该恶意 IP 恰好也提供 HTTPS 服务（甚至证书可绕过），HSTS 反而会强制浏览器连向这个恶意 HTTPS 站点——此时它不仅不防御，还可能加剧风险。
所以，真正要测的不是“HSTS 能否防 DNS 劫持”，而是：
✅ 在 DNS 劫持发生时，HSTS 是否仍能阻止用户误用 HTTP 协议访问（即防止明文传输被监听/篡改）；
❌ 它无法阻止用户访问到错误的服务器 IP（无论 HTTP 还是 HTTPS）。
一、验证 HSTS 是否已正确加载（跨操作系统）
HSTS 状态由浏览器本地维护，与操作系统无关，但需确认各平台主流浏览器是否已记住你的域名策略：
-
Windows/macOS/Linux（Chrome / Edge / Firefox）：
打开chrome://net-internals/#hsts（Chrome/Edge）或about:config搜索network.http.stricttransportsecurity.enabled（Firefox），手动查询域名：Query domain: example.com
若返回
Found且max-age > 0，说明策略已生效。 -
macOS Safari：
无图形界面查询入口，可通过终端命令间接验证（需已访问过 HTTPS 站点）：defaults read ~/Library/Cookies/HSTS.plist
或更可靠方式：使用
curl -I https://example.com确认响应头存在，再在 Safari 中访问http://example.com—— 应自动跳转至 HTTPS，且地址栏显示锁图标。 Android / iOS 移动端：
Chrome for Android 同样支持chrome://net-internals/#hsts；
iOS Safari 不开放 HSTS 状态查询，但行为一致：首次 HTTPS 访问后，后续http://输入会自动升级。
✅ 关键检查点：在任意系统上，打开无痕窗口 → 输入
http://example.com→ 观察是否未经任何 HTTP 响应，直接发起 HTTPS 请求（开发者工具 Network 面板中看不到http://的请求记录）。这是 HSTS 生效最直观的表现。
二、模拟本地 DNS 劫持，观察 HSTS 行为边界
目的不是看 HSTS “拦不拦住劫持”，而是看它在劫持存在时是否仍坚守 HTTPS 强制规则。
步骤（以 macOS/Windows 为例）：
-
修改 hosts 文件，将你的域名指向一个可控的恶意 IP（如
127.0.0.1或测试服务器 IP）：127.0.0.1 example.com
- 确保该 IP 上运行一个 HTTPS 服务（哪怕自签名证书），监听 443 端口；
- 清除浏览器 HSTS 缓存（或使用全新无痕窗口 + 首次访问）；
-
访问
https://example.com：- 浏览器会连接
127.0.0.1:443，显示证书警告（因域名不匹配）； - 若你点击“继续访问”，且服务返回了有效的
Strict-Transport-Security头，浏览器就会记住该策略；
- 浏览器会连接
-
再访问
http://example.com：- HSTS 仍会触发，自动跳转到
https://example.com→ 实际连向127.0.0.1:443； - 用户看到的仍是恶意 HTTPS 站点，但全程没有明文 HTTP 流量。
- HSTS 仍会触发，自动跳转到
⚠️ 这说明：HSTS 在 DNS 劫持下，保障的是协议层安全（无明文），而非目标真实性（防错连）。防错连需靠 DNSSEC、证书校验、CAA 记录等其他机制。
三、真正防御本地 DNS 劫持的配套措施
HSTS 必须和以下手段配合，才能形成完整防护：
- DNSSEC 部署：确保 DNS 解析结果不可篡改，从源头阻断劫持；
- HTTPS 全站覆盖 + 有效证书：避免用户因证书错误习惯性忽略警告；
- 预加载（preload）提交：让主流浏览器在首次访问前就内置你的 HSTS 策略，绕过“首次 HTTP 访问”风险；
-
Hosts 文件监控（终端侧）：用脚本定期比对
/etc/hosts或C:\Windows\System32\drivers\etc\hosts是否含异常条目； - 网络层 DNS 强制策略（企业环境）：如通过 DHCP 分发可信 DNS，或部署 DoH/DoT 客户端锁定解析路径。
四、快速验证命令汇总（一次到位）
# 1. 检查 HTTPS 响应头是否含 HSTS
curl -I https://example.com | grep -i "strict-transport-security"
# 2. 检查是否跳转（HTTP → HTTPS）
curl -I http://example.com -L -s -o /dev/null -w "%{url_effective}\n"
# 3. 查看当前系统 hosts 是否污染
grep "example.com" /etc/hosts 2>/dev/null || echo "not found in hosts"
# 4. （Linux/macOS）检查 DNS 解析是否异常
dig +short example.com @114.114.114.114
dig +short example.com @8.8.8.8
# 对比结果是否一致HSTS 不是 DNS 防御工具，它是 HTTPS 信任链的加固环节。把它放在正确的定位里，才能用得准、测得清。
