Zotero 和知网同时打不开：一次 Windows 网卡 DNS 异常排查

最初的故障只发生在 Zotero：同步时提示无法建立到 api.zotero.org 的安全连接，错误代码为 SSL_ERROR_BAD_CERT_DOMAIN（证书域名不匹配）。从表面看，这很像某个境外服务的连接问题，甚至容易让人先怀疑 IPv6、代理或 Zotero 本身。

真正改变排查方向的，是后来发现同一台电脑上的知网也打不开。一个是境外文献管理服务，一个是国内学术网站；当两个没有直接关系的网站同时出现证书异常或连接失败时，问题通常已经不在某个应用内部，而在这台电脑共用的网络配置上。

这次故障最终定位到 Windows 无线网卡的 DNS 配置。修复后，知网与 Zotero API 都返回 200，完整证据链由此闭合。

1 故障现象：证书报错只是结果

Zotero 最初显示：

不安全的连接
Zotero 无法建立到 api.zotero.org 的安全连接。
错误代码：SSL_ERROR_BAD_CERT_DOMAIN

这个错误表示客户端请求了一个域名，实际连接对象提供的证书却不属于它。Zotero 官方文档也把这类提示归入“电脑或网络中的某个环节正在拦截连接”的范围，可能涉及代理、安全软件、机构网络或其他网络配置。

但这只是一个方向，不等于已经找到根因。证书不匹配也可能发生在 DNS 把域名解析到错误地址以后：客户端访问的域名没有写错，只是被带到了不该去的服务器。

2 第一层误判：是不是 IPv6 导致的

先查看 api.zotero.org 当前解析到什么地址：

1
Resolve-DnsName api.zotero.org

当时得到的是两个 IPv4 地址：

1
2
27.124.42.50
189.24.82.252

这里已经可以排除最初那个“IPv6 优先连接导致异常”的猜测，因为结果中根本没有 AAAA（IPv6 地址记录）。真正值得追问的是：这些 IPv4 地址是不是当前网络应该返回的结果。

接下来又通过公共解析服务查询，并测试了多个地址的 443 端口。这一步能帮助判断“解析结果是否一致”“目标端口是否可连接”，但不能仅凭 IP 段就断言某个地址一定属于 Zotero，更不能把一次能连接的云端 IP 当成永久地址。

云服务节点会变化，单个 IP 只能作为当时的诊断样本。

3 临时写入 hosts，为什么还不算修好

为了绕过当前 DNS，可以把一个已经通过 HTTPS 验证的地址临时写入系统 hosts：

1
44.216.174.187 api.zotero.org

这一步让 api.zotero.org 固定指向某个当时可用的节点，适合做反向验证：如果绑定后 Zotero API 恢复，就说明原来的解析链路确实存在问题。

但接下来出现了两个新现象：

  • 浏览器访问 www.zotero.org 仍然提示 ERR_CERT_COMMON_NAME_INVALID（证书通用名称无效）；
  • 知网也无法正常打开。

这说明故障不是 api.zotero.org 一个域名的孤立问题。修改 hosts 只绕过了其中一个入口，整台电脑仍在使用有问题的 DNS 配置。

因此，这里不能把“某个 API 暂时恢复”当成排查结束。当多个无关网站一起异常时，应该从应用层退出，检查系统代理、默认网关和网卡 DNS。

4 排除代理，再检查网卡 DNS

先查看 Windows 当前是否启用了系统代理，并记录默认网关：

1
2
3
4
5
6
7
8
9
10
11
$proxy = Get-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' |
  Select-Object ProxyEnable, ProxyServer

$gateway = Get-NetRoute -DestinationPrefix '0.0.0.0/0' |
  Select-Object -ExpandProperty NextHop -First 1

[PSCustomObject]@{
  ProxyEnable   = $proxy.ProxyEnable
  ProxyServer   = $proxy.ProxyServer
  DefaultGateway = $gateway
} | Format-List

当时的结果是：

1
2
3
ProxyEnable   : 0
ProxyServer   :
DefaultGateway: 192.168.0.1

系统代理没有开启，于是继续查看各网卡实际使用的 IPv4 DNS：

1
2
3
4
Get-DnsClientServerAddress -AddressFamily IPv4 |
  Where-Object { $_.ServerAddresses.Count -gt 0 } |
  Select-Object InterfaceAlias, ServerAddresses |
  Format-Table -AutoSize

这一次终于出现了决定性线索：

1
2
3
InterfaceAlias  ServerAddresses
--------------  ---------------
WLAN            {45.129.11.136, 180.76.76.76}

问题电脑的无线网卡并没有使用预期的自动 DNS，而是被静态配置了这两个地址。仅凭地址本身无法证明它们为什么出现在这里，也不必贸然定性为恶意篡改；但结合此前多个域名解析异常、证书不匹配以及国内外网站同时故障，这组网卡 DNS 配置已经成为最值得验证的变量。

5 修复顺序：先恢复默认，再考虑公共 DNS

下面命令需要在“以管理员身份运行”的 PowerShell（命令行环境）中执行。网卡名称不一定都叫 WLAN，应以前一步输出的 InterfaceAlias 为准。

5.1 先保存当前配置

在改动之前，把原配置留一份记录：

1
2
Get-DnsClientServerAddress -InterfaceAlias 'WLAN' -AddressFamily IPv4 |
  Format-List | Out-File "$env:USERPROFILE\Desktop\dns-before.txt" -Encoding utf8

5.2 优先恢复 DHCP 下发的默认 DNS

如果没有明确理由使用静态 DNS，最小改动是先恢复网络自动分配：

1
2
Set-DnsClientServerAddress -InterfaceAlias 'WLAN' -ResetServerAddresses
Clear-DnsClientCache

微软对 Set-DnsClientServerAddress（设置 DNS 客户端服务器地址）的说明很明确：-ResetServerAddresses 会把 DNS 地址恢复为默认值，也就是重新使用 DHCP 等网络配置提供的结果。

5.3 默认 DNS 仍异常时，再指定可信公共 DNS

如果当前路由器或网络下发的 DNS 本身也有问题，可以改用阿里公共 DNS：

1
2
3
4
5
Set-DnsClientServerAddress `
  -InterfaceAlias 'WLAN' `
  -ServerAddresses ('223.5.5.5','223.6.6.6')

Clear-DnsClientCache

223.5.5.5 和 223.6.6.6 是阿里公共 DNS 官网公开的 IPv4 地址。这里使用它们，是因为本次故障环境位于国内，并且修复后实际验证通过；这不表示所有网络都必须使用同一组 DNS。

5.4 清理排查时添加的 hosts 临时绑定

如果此前曾加入：

1
44.216.174.187 api.zotero.org

修复 DNS 后应从下面的文件中删除这一行：

1
C:\Windows\System32\drivers\etc\hosts

固定云端 IP 适合短时验证，不适合长期保留。否则节点变化以后，旧的 hosts 记录会绕过正常 DNS，再次制造难以解释的连接问题。

6 验证：不要只测试 Zotero

修复后的验证应覆盖两个无关站点，这样才能确认系统解析链路已经恢复，而不是某一个域名被临时绕过。

先重新查看网卡 DNS 和解析结果：

1
2
3
Get-DnsClientServerAddress -InterfaceAlias 'WLAN' -AddressFamily IPv4
Resolve-DnsName api.zotero.org -Type A
Resolve-DnsName www.cnki.net -Type A

再做端到端 HTTPS 请求：

1
2
3
4
5
6
7
8
9
10
11
try {
  $cnki = (Invoke-WebRequest -Uri 'https://www.cnki.net' -UseBasicParsing -TimeoutSec 10).StatusCode
  $zotero = (Invoke-WebRequest -Uri 'https://api.zotero.org' -UseBasicParsing -TimeoutSec 10).StatusCode

  [PSCustomObject]@{
    CNKI_Status   = $cnki
    Zotero_Status = $zotero
  } | Format-List
} catch {
  $_.Exception.Message
}

本次修复后的结果是：

1
2
CNKI_Status   : 200
Zotero_Status : 200

到这里，证据链才算闭合：修改网卡 DNS、清空缓存之后，两个此前同时异常的网站都恢复了 HTTPS 访问。

7 这次排查真正值得记住的四个判断

现象 容易产生的误判 更稳妥的判断
Zotero 报证书域名不匹配 Zotero 自己坏了 先检查实际解析地址与证书来源
怀疑 IPv6 直接关闭 IPv6 先看是否真的存在 AAAA 记录
写入 hosts 后 API 恢复 问题已经解决 这只证明原解析链路有问题
Zotero 与知网同时异常 两个网站碰巧都故障 优先检查系统代理、网卡 DNS 与局域网配置

这次最关键的转折，不是找到了某个“正确 IP”，而是意识到排查对象已经从单个应用变成了整台电脑的网络解析入口。

如果只修 Zotero，可以临时绑定一个地址；如果要修好电脑，就必须回到网卡 DNS。前者是绕行，后者才是恢复正常路径。

8 参考资料