1. 先把“红叉”翻译成人话：症状分类与影响面判断

ArcGIS 界面里那个红色小叉号，是很多人入门阶段最不想见到的图标。它不像报错弹窗那样给你一串英文，也不像崩溃那样干脆利落，它就安安静静地挂在那儿，提示你“某个在线资源没连上”。但同样是红叉，背后的病灶可能横跨网络、证书、代理、权限、运行时五六个层面。我这些年帮人看过的案例里，有相当一部分人第一反应是卸载重装，结果折腾一下午，问题原封不动——因为病根根本不在软件本体上。这篇内容就是把我自己踩过的和帮别人排查过的路径整理出来，适合所有被“无法验证登录信息”卡住的 GIS 使用者，从刚接触在线底图的新手到需要维护一批终端的老手，都能按图索骥走一遍。

“无法验证登录信息”这句提示，字面意思是客户端把凭据发出去之后，没拿到一个可信的、预期的应答。注意这里的关键词是“应答”，不是“发送”。很多人看到这句话就认定是自己密码打错了，反复输入、反复重置，其实凭据早在第一步就发出去了，真正断掉的是后面那次握手或者那次令牌交换。所以第一步永远不是改密码，而是搞清楚：请求到底走到哪一步停的。

1.1 三种“红叉”长得很像，病灶完全不同

我习惯按出现位置把这类故障分成三档，分档之后排查方向立刻收窄一半。第一档是登录界面直接报错，弹窗里出现“无法验证登录信息”或者“凭据无效”之类的文案，这说明认证请求压根没走通；第二档是登录成功、账号头像也正常显示，但工程里的在线底图、要素服务一个个全挂着红叉，这说明认证通了、业务请求没通；第三档是只有某几个特定服务红叉，其余正常，这基本可以锁定在单个服务的地址、权限或者服务端状态上。

这三档对应的排查入口完全不同。第一档要从域名解析、TLS 握手、代理认证这些“链路层”的东西查起；第二档要重点看令牌刷新、客户端时间、缓存里的过期凭据；第三档几乎可以直接跳过网络排查，去看服务地址有没有拼错、账号有没有该服务的访问权限。我见过太多人拿着第三档的问题去重装第一档的组件，纯属方向性浪费。

判断自己属于哪一档有个很土但很有效的办法：打开软件的同时开一个抓包工具或者干脆看系统日志里的连接记录，观察请求是“一个都没发出去”还是“发出去被拒”还是“发出去拿到了 200 但内容为空”。这三种状态在排错时是三条完全不同的岔路。

注意：不要用“能不能打开网页”来判断在线资源是否可用。浏览器和桌面客户端走的可能是两套网络栈、两套证书存储、两套代理配置，浏览器能开不代表客户端能连，反过来也一样。

1.2 登录失败为什么会连累底图

这里稍微解释一下机制，理解了机制你排查起来会快很多。现在的桌面 GIS 客户端在访问在线资源时，主流做法是基于令牌的认证：先用账号换取一个有时效的令牌字符串，之后每次请求都把这个令牌塞在请求头里带过去。令牌有有效期，通常是几十分钟到几小时，客户端会在后台自动续期。如果续期那一步失败了——比如网络抖动、系统时间偏移、证书链校验不过——客户端手里就攥着一个过期令牌，后续所有请求都被服务端拒绝，表现到界面上就是一片红叉。

这就解释了一个常见现象：早上打开还好好的，中午出去吃个饭回来全红了。不是软件坏了，是令牌过期且续期失败。同理，如果系统时间被手动改过、时区设错、或者主板电池没电导致时间漂移，令牌的签发时间和校验时间对不上，服务端会直接判为无效。这个坑在虚拟机里特别常见——挂起再恢复之后，虚拟机时间可能还停留在几天前。

还有一层是证书信任。客户端校验服务端证书时，会沿着证书链一路往上游找根证书。如果中间某张证书缺失、根证书库太旧、或者系统里被塞了一张来路不明的中间证书，校验就会失败。失败的结果不一定是弹窗，很多时候就是静默拒绝，然后你看到红叉。所以我在排查这类问题时，会先把“链路是否可信”和“凭据是否有效”当成两个独立的问题分开验证。

2. 排错主线：一条从外到内的五层漏斗

2.1 为什么我坚持“先网络后软件”

新手最容易犯的错是从最里面往外查：先重装软件，再重建配置，最后才想起来 ping 一下。这个顺序反了。软件重装成本高、耗时长，而且九成情况下无效；网络验证成本极低，一条命令几秒钟出结果，还能一次性排除掉一大片可能性。我自己的习惯是，任何“连不上”的问题，前十分钟全部花在链路上，一行软件配置都不碰。

另一个理由是，由外向内排查能形成证据链。你能明确地说出“域名解析正常、443 端口可达、TLS 握手成功、证书链完整、代理未拦截”，这五条结论摆出来之后，问题就只能是软件侧的了，这时候再去动配置心里有底。反过来，如果先动了软件配置，之后即使问题解决了，你也不知道是哪一步修好的，下次再遇到还得重新摸一遍。

2.2 五层漏斗的具体划分

我把这套流程固化成五层，从外到内依次是：连通性与域名解析、TLS 握手与证书信任、系统代理与 Internet 选项、软件自身登录态与缓存、权限与运行时环境。每一层都有明确的“通过标准”，通过了就往下一层走，不通过就当场处理，处理完再回头验证。

这个表我一般是贴在便签上按顺序走。实践下来，八成问题栽在第一层和第三层，第二层和第五层次之，第四层反而最少——因为软件自身的登录态问题通常有明显特征，比如刚改过密码、刚换过账号。

3. 第一层：连通性与域名解析，别急着怀疑软件

3.1 三条命令定位“通不通”

第一层我只用三条命令，Windows 下自带，不需要装任何东西。第一条ping 登录域名，看能不能拿到 IP。注意这里的目的不是看延迟，是看解析结果。如果返回“找不到主机”，那就是 DNS 的问题，后面的都不用查了。第二条nslookup 登录域名 8.8.8.8，指定一个外部 DNS 再解析一次，这一步是为了区分“本地 DNS 服务器有问题”还是“域名本身有问题”。如果本地解析失败、指定外部 DNS 能成功，那基本可以确定是本地 DNS 配置或者内网 DNS 缓存的问题。

第三条是端口连通性。Windows 上可以用 PowerShell 的Test-NetConnection：

Test-NetConnection 登录域名 -Port 443 -InformationLevel Detailed

输出里重点看TcpTestSucceeded是否为True。这一步比 ping 更有价值，因为很多网络策略会禁掉 ICMP 但放行 443，ping 不通不代表服务不可达。反过来，ping 通了但 443 不通，说明中间有设备在拦端口，这时候你去查软件配置是白费力气。

# Linux 或 macOS 环境下等价的做法 nc -vz 登录域名 443 curl -v --max-time 20 https://登录域名/ -o /dev/null

curl -v那一条特别有用，它会把 DNS 解析、TCP 连接、TLS 握手、HTTP 响应整个过程逐行打出来。哪一步卡住，一眼就能看到。我经常让人把这段输出截图发我，比我远程问十个问题都高效。

3.2 DNS、IPv6 与 hosts 的隐形干扰

DNS 这块有几个很隐蔽的坑。第一个是 DNS 缓存污染：内网 DNS 曾经把某个域名解析到一个已经下线的旧地址，缓存没刷新，客户端一直往旧地址打。处理办法是ipconfig /flushdns清一下，再试。第二个是 hosts 文件被人手工写过条目，指向了一个测试环境或者已经废弃的 IP。这个尤其容易出现在“之前有人为了测试临时改过、后来忘了删”的机器上。检查一下C:\Windows\System32\drivers\etc\hosts，把和登录域名相关的行注释掉再试。

第三个是 IPv6。现在很多网络环境同时下发 IPv4 和 IPv6 地址，如果 IPv6 那条路实际不通、但系统优先走 IPv6，就会出现“解析得到地址、连接超时”的怪现象。验证方法是用ping -4 登录域名强制走 IPv4，如果 IPv4 通、默认不通，那问题就在 IPv6 路由上。临时处理可以在网卡属性里取消勾选 IPv6，但这是权宜之计，长期还是得让网络管理员把 IPv6 路由修好。

提示：改 hosts 和网卡属性都属于系统级改动，动手前先记下原始状态，出问题能退回去。我见过有人为了排查把 IPv6 关了，后来忘了开，导致另一套内网系统连不上，又折腾半天。

还有一类是企业内网的拆分解析（split DNS）：内网 DNS 把某个域名解析到内网地址，而这个内网地址只对内网服务开放。如果客户端不在内网、或者连错了网段，解析出来的地址就是不可达的。这种时候表现往往是“能解析、连不上”，和 DNS 故障很像但处理方式完全不同，需要确认当前所处的网络位置。

4. 第二层：TLS 握手与证书信任链

4.1 用 curl 和 openssl 看握手过程

第一层通过之后，第二层就是看握手。最直接的工具还是curl，加-v参数能看到协商出来的 TLS 版本和加密套件。如果输出停在TLS handshake那里不动，或者报SSL_connect error，那就是握手阶段出问题了。常见原因有三个：客户端不支持服务端要求的最低 TLS 版本、双方没有共同支持的加密套件、中间有设备做了 TLS 拦截但证书不被信任。

想看得更细一点，用openssl：

openssl s_client -connect 登录域名:443 -servername 登录域名 -showcerts

-servername这个参数很关键，很多服务端会根据 SNI 返回不同的证书，不带这个参数拿到的可能是默认证书，验证结果会有偏差。输出里会打印整条证书链，你要关注的是最上面那几行的Verify return code，如果是0 (ok)就说明校验通过，如果是20 (unable to get local issuer certificate)之类的，就是证书链不完整。

在 Windows 上还有个更省事的办法，把证书导出来用certutil验：

certutil -verify -urlfetch 证书文件.cer

-urlfetch会尝试联网拉取中间证书做完整性校验，能明确告诉你缺哪一张。这个方法我特别推荐，因为它给的是确定结论，不用靠猜。

4.2 证书链、系统时间与根证书更新

证书链不完整是最常见的 TLS 问题。表现是浏览器能开（浏览器自己有补链机制），客户端不能开。解决办法有两个方向：一是让服务端把完整的证书链配好，这是根治；二是客户端这边手工把缺失的中间证书导入到“受信任的根证书颁发机构”或者“中间证书颁发机构”存储区。后者是权宜之计，但现场应急很管用。

导入的方法：把证书文件双击打开，选择“安装证书”，存储位置选“当前用户”或“本地计算机”，然后手动指定存储区。注意别一股脑全塞进“受信任的根证书颁发机构”，中间证书应该放“中间证书颁发机构”，放错位置反而不生效。导入完记得重启客户端，很多程序只在启动时读一次证书存储。

系统时间是另一个高频杀手。时间偏差超过几分钟，令牌校验就会失败，而且报错信息通常很含糊。检查命令：

w32tm /query /status w32tm /resync

第一条看当前时间源和偏差，第二条强制同步。如果同步失败，检查一下时间服务有没有被禁用，或者防火墙有没有挡住时间同步端口。虚拟机用户尤其要注意，挂起恢复之后时间可能严重漂移，我一般会在虚拟机里配一个开机自动同步的脚本。

根证书库太旧也会出问题。操作系统版本比较老、长期没打过补丁的机器，根证书库可能停留在几年前，新签发的证书链根本认不出来。这种情况的处理方式是安装最新的根证书更新包，或者干脆升级系统。我遇到过一台跑了七八年的工控机，怎么都连不上，最后发现是根证书库太老，更新完立刻正常。

5. 第三层：系统代理与 Internet 选项的坑

5.1 WinHTTP 与 WinINET 两套代理

Windows 上有两套互相独立的代理配置，这是很多人不知道的。一套叫 WinINET，就是“Internet 选项”里那个，主要服务于浏览器和一部分调用系统 API 的程序；另一套叫 WinHTTP，服务于系统服务和另一批程序。两套配置各存各的，改了一套另一套不变。桌面 GIS 客户端用哪一套，取决于它的网络组件怎么写的，有的用这套有的用那套，甚至同一个软件的不同模块用的都不一样。

查看 WinHTTP 配置：

netsh winhttp show proxy

查看 WinINET 配置，最直观的是打开“Internet 选项 → 连接 → 局域网设置”，看有没有勾选代理服务器、地址端口是什么、有没有勾“使用自动配置脚本”。命令行也能看：

reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyServer reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v AutoConfigURL

三行分别对应“代理是否启用”“代理地址”“PAC 脚本地址”。我遇到过最典型的情况是：机器以前在某个需要代理的网络环境里用过，代理配置留在注册表里没清，后来换了网络环境，浏览器因为走 PAC 自动判断所以正常，客户端死读那条静态代理，当然连不上。这种情况把ProxyEnable改成 0，或者直接把代理地址清空就行。

5.2 注册表里的残留与 PAC 脚本

比静态代理更隐蔽的是 PAC 脚本残留。AutoConfigURL指向一个脚本地址，脚本会根据目标域名决定走不走代理。如果那个脚本服务器已经不可达，系统解析 PAC 就会超时，表现是“所有请求都慢半拍然后失败”。这种情况在浏览器里可能有缓存所以不明显，客户端每次都要重新拉脚本，直接卡死。

处理方式很直接：把AutoConfigURL这一项删掉或者置空，然后在“Internet 选项”里取消勾选自动配置。删之前备份一下注册表项，用reg export导出一份。

reg export "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" 备份.reg

还有一种情况是代理需要认证，但客户端不支持弹窗输入凭据，导致请求一直挂在 407 上。这种在企业网络里很常见。判断方法是看curl -v的输出里有没有407 Proxy Authentication Required。如果是，要么让客户端支持凭据，要么在网络侧给这台机器放行，要么换一个不需要认证的出口。

注意：改代理配置前一定先问清楚当前网络环境到底需不需要代理。有些单位的内网必须走代理才能出去，你把代理一关，原本能用的功能也废了。我一般会先拿浏览器做对照实验：浏览器能访问，说明当前代理配置对浏览器是有效的；然后看客户端是不是用了同一套配置。

另外提一句 Internet 选项里的“安全”选项卡。老版本的桌面 GIS 大量依赖系统自带的浏览器控件来渲染登录页面，如果“本地 Intranet”“受信任的站点”这些区域的安全级别被调得过高，或者登录域名被误加进了“受限制的站点”，登录窗口就会白屏或者直接失败。检查一下受限站点列表里有没有你的登录域名，有的话删掉。这个坑在老机器上出现频率相当高，因为很多单位的组策略会统一推送安全区域设置。

6. 第四层：软件自身的登录状态与缓存

6.1 彻底注销与重建登录态

前面三层都过了，问题就在软件自己身上。第一件事不是清缓存，是彻底注销。很多客户端有“记住我”之类的选项，登录信息存在本地，注销的时候只清了界面状态没清磁盘上的凭据，重新登录还是拿旧的去试，当然失败。正确做法是在软件里找到注销入口，注销之后完全退出程序（包括托盘图标和后台进程），确认任务管理器里没有残留进程，再重新打开登录。

如果注销之后还是不行，检查一下本地凭据存储。Windows 的“凭据管理器”里可能存着一条旧的登录记录，地址或者账号变了但记录还在。打开“控制面板 → 凭据管理器 → Windows 凭据”，找找有没有和登录域名相关的条目，有的话删掉。这一步不需要什么技术含量，但经常一击命中。

还有一种情况是账号本身的状态问题：密码刚改过、账号被锁、需要二次验证但客户端版本不支持。这类问题从客户端这边是查不出来的，只能通过网页端登录一次来验证账号是否正常。我的习惯是先用浏览器登录同一个账号，如果浏览器能登、客户端不能登，那基本可以确定是客户端侧的问题；如果浏览器也登不上，那就别在客户端上浪费时间了。

6.2 配置目录与缓存清理的正确姿势

清理配置目录要谨慎，因为它里面既有缓存也有你的个性化设置，全删了等于恢复出厂。我的做法是先重命名而不是删除，把配置目录改成带日期的备份名，让软件重新生成一份干净的，验证问题是否解决。解决了再决定要不要把旧目录里的设置迁移回来；没解决就把旧目录改回去，一点损失没有。

配置目录一般位于用户目录下的AppData\Local里，是以产品名命名的文件夹。具体路径不同版本不一样，可以在软件的“关于”或者“设置”里找到当前使用的配置路径。清理的重点是缓存子目录和日志子目录，配置文件本身可以先留着。

日志是排查的富矿，但很多人不看。客户端一般会把网络请求的详细过程写进日志文件，包括请求了哪个地址、返回了什么状态码、报了什么错。打开日志搜一下登录域名相关的行，往往能直接看到401、403、timeout这类明确的状态码，比看界面上的模糊提示有用一百倍。日志一般按日期滚动，找当天的那个文件，从后往前看。

# 在配置目录里按修改时间找最近的日志文件 Get-ChildItem -Path "$env:LOCALAPPDATA" -Recurse -Filter "*.log" -ErrorAction SilentlyContinue | Sort-Object LastWriteTime -Descending | Select-Object -First 10 FullName, LastWriteTime

这条命令能快速定位最近被写过的日志。找到之后用文本编辑器打开，搜error、fail、timeout、401、403这些关键词。

7. 第五层：权限、运行环境与版本兼容

7.1 权限与安装路径

走到第五层，说明链路、证书、代理、登录态全都正常，问题出在运行环境。首先要确认的是权限。客户端需要在用户目录下写缓存、写日志、写配置，如果当前账号对这些目录没有写权限（比如用了受限账户、或者目录被安全软件锁了），就会出现“能连上但存不下令牌”的诡异现象，表现依然是登录失败。

快速验证方法是用管理员身份运行一次。如果管理员身份能正常登录，普通身份不行，那基本就是权限问题。这时候不要图省事长期用管理员跑，应该去把对应目录的权限配好。需要检查的目录通常包括配置目录、临时目录、以及软件安装目录下的某些子目录。

安装路径里的中文和空格也是个老生常谈的坑。虽然现在的版本对中文路径的支持比早期好很多，但某些组件依然会在路径处理上出问题，尤其是涉及临时文件解压、插件加载的环节。安装路径尽量用纯英文、无空格，这是我从早期版本就养成的习惯，一直保持到现在，省了很多莫名其妙的麻烦。

7.2 浏览器内核组件与 .NET 运行时

现代桌面客户端的内嵌网页普遍不再用系统自带的浏览器控件，而是自带一套独立的内核，或者依赖系统里的某个运行时组件。这类组件缺失或者版本不对，表现就是登录窗口打不开、白屏、或者加载到一半卡住。检查方式是看安装目录下有没有对应的运行时文件夹，以及系统里有没有装对应的运行库。

.NET 运行时的版本检查：

reg query "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full" /v Release

拿到的Release值对照版本表，确认是否满足软件的最低要求。如果系统里的版本太老，装一下新版运行库，重启再试。这一步不要省略，我遇到过好几例都是运行库版本差一点导致的登录异常，界面上完全看不出原因。

还有一类是安全软件拦截。某些安全软件会对程序的网络请求做深度检测，检测过程中可能中断 TLS 连接，导致客户端看到的是一个“被篡改”的证书，校验自然失败。判断方法是临时退出安全软件再试一次（注意是临时，验证完立刻恢复）。如果退出后正常，那就去安全软件里给这个程序加白名单，而不是长期关着。

8. 常见问题速查表与我的避坑心得

8.1 速查表

把上面五层里最高频的问题整理成一张表，遇到故障先扫一遍，能省不少时间。

8.2 几条用血换来的经验

第一条，永远先做对照实验。浏览器和客户端是一组天然的对照，一个通一个不通，问题的范围立刻就缩小到“两者差异”上；两个都不通，问题在链路或者账号上。这个思路比任何工具都好用，因为它不需要你先懂原理。

第二条，改任何东西之前先备份。注册表导出、配置文件重命名、hosts 复制一份，这些动作加起来不超过一分钟，但能让你在改错之后三十秒内回到原点。我见过太多人一路改下去，改到最后自己也说不清改了什么，只能重装系统。

第三条，一次只改一个变量。同时改 DNS、关代理、清缓存，然后问题好了——你根本不知道是哪一步起的作用，下次遇到还是不会。慢就是快，这条在排错上体现得特别明显。

第四条，日志比界面提示可信。界面上的文案为了“友好”往往含糊其辞，日志里写的才是真实的状态码和错误信息。养成出问题第一件事翻日志的习惯，能省掉大量猜测。

第五条，版本兼容性要提前确认。软件版本、操作系统版本、运行库版本、证书库版本，这四个东西任何一个太旧都可能出问题。我现在的做法是，接手一台新机器先花五分钟把这四项版本号记下来，以后出问题一对照就知道是不是环境变了。

最后分享一个我自己常用的笨办法：准备一个最小复现环境。找一个干净的系统、装同一个版本、用同一个账号登录一次。如果干净环境能登、出问题的机器不能登，那问题百分之百在那台机器的环境上，跟账号、跟服务端、跟网络策略都没关系。这个办法看着麻烦，实际上比在一台已经被改得面目全非的机器上瞎猜要快得多，尤其是那种“之前好好的，不知道谁动了什么”的场景，一步到位。