FortiClient 卡在 98%：关闭该网卡的 IPv6

进度条走到 98%，客户端就停在那里，重新输入密码毫无作用。这才是有用的线索：客户端已经接受了网关证书、发送了凭据并收到了隧道配置。剩下的就是把虚拟网卡启动起来，并确认隧道能够承载流量。当最后这一步始终无法完成时，故障就在本地，再怎么重输凭据也触不到它。

一共四步，第一步是读日志，而不是看进度条。

98% 这个计数器究竟在报告什么

这个百分比是客户端自己的阶段计数器，而不是吞吐量指标。每次尝试都卡在同一个数字，说明客户端走到了某个特定阶段并在等待；这也是为什么慢速连接和卡死的客户端在日志里看起来不一样。如果是凭据问题，日志会打印凭据错误，而不是无声地停住。

Fortinet 把这个症状归结为客户端侧的一个原因：客户端所用网卡上的 IPv6 是启用的。因此网卡设置是第一个要测试的东西，而不是所有 SSL-VPN 卡顿的通用解释。

第 1 步：先读日志，再看进度条

在改动任何东西之前，先抓取卡住那一刻之前的几行。你要看的是：隧道网卡有没有被创建、有没有分配到地址、客户端是不是放弃等待某一类地址。卡在别的百分比意味着另一个阶段，诊断也不同；证书警告或错误的网关地址会给出各自的报错，而不是无声等待。把时间戳记下来，因为下一次尝试会往同一个文件里追加新的一段。

如果日志显示登录已完成、之后再无下文，那你就在本地配置环节，网卡是合理的嫌疑对象。

第 2 步：把 IPv6 的改动限定在一块网卡上

改动应该落在网卡上，而不是整台机器上。在 Windows 的网卡属性里，这意味着在特定接口上取消勾选 Internet Protocol Version 6 (TCP/IPv6)；从命令行看则是 Disable-NetAdapterBinding -Name "Ethernet 2" -ComponentID ms_tcpip6。重新连接之前，用 Get-NetAdapterBinding -ComponentID ms_tcpip6 确认状态。然后再连一次，观察进度条是越过 98% 还是依旧停在那里。

先限定范围，再测试。全局关闭 IPv6 是比问题所需更大的改动，还会影响你并不打算触碰的服务。

第 3 步：核实卡顿掩盖了什么

能连上的隧道不等于能用的隧道。检查客户端分配的地址、配置文件安装的路由，以及一台内网主机的名称解析：Resolve-DnsName files.corp.example。连上却什么都解析不了的客户端是 DNS 出了问题，而这很容易被误读成同一个故障又回来了。

按名称测试一个内网资源，再测试一个公网目标，这样坏掉的拆分隧道才不会被当成已经修好的客户端。

第 4 步：让修复可以重复

如果这个设置要覆盖整个机群，就把它放进部署包或网卡配置里，而不是在每台笔记本上重复手工操作。在工单里记录：98% 的卡顿与网络接口上的 IPv6 有关；并注明这台主机上还有哪些东西依赖 IPv6，以免有人为了修别的问题又把它打开。

只存在于某位工程师记忆里的修复，就是下个季度还会回来的修复。

如果关掉 IPv6 后进度条仍停在 98%，厂商的说明就不再解释它了，日志才是你的下一个证据。别再治标，回到阶段计数器本身。