周五下午快下班的时候，一位同事把笔记本推到我工位上，屏幕上 ArcGIS Pro 右上角挂着一个刺眼的红色小叉，鼠标悬停提示“无法验证登录信息”，左侧目录里的在线底图、影像服务和协作项目全部灰掉，可本地那几份 shapefile 打开得又快又稳。这个画面但凡在 GIS 圈子里干过两年的人都不会陌生——小红叉并不代表软件坏了，它只说明一件事：客户端跟在线资源之间那条鉴权链路断了。在线资源连不上，ArcGIS 就退化成一个大号的本地看图工具，底图、地理编码、路径分析、共享协作统统歇菜。这篇记录就是围绕“无法验证登录信息”这一个报错，把我从现象复现、链路拆解、逐层排查到最终连通的完整过程摊开讲清楚，顺带把每一步背后的原理和踩过的坑一并交代。如果你正好在找“ArcGIS 小红叉怎么去掉”“在线资源连不上怎么办”，或者你负责给团队做桌面 GIS 的环境支撑，这篇可以直接拿去对照着做。

1. 先说清楚这个小红叉到底在闹什么

1.1 现象复述与我接手时的第一判断

那台机器的表现很有代表性：ArcGIS Pro 可以启动，本地地理处理工具能跑，工程文件保存正常，唯独右上角用户头像位置是个红叉，点击“登录”会弹出一个转圈的对话框，转十几秒后退回原样，报错文案是“无法验证登录信息，请检查网络连接和凭据”。更麻烦的是，即使不点登录，只要往地图里拖一个在线底图，图层也会一直停在“正在加载”状态，最后变成感叹号。这种“本地全好、在线全废”的组合，基本可以把显卡驱动、软件崩溃、工程文件损坏这几类原因直接排除掉，问题一定卡在客户端发起的那一次 HTTPS 请求上。

我接手之后没有立刻动它，而是先做了两件事：第一，用同一台机器打开系统自带浏览器，访问在线服务的主站首页；第二，换一台坐在同一张办公桌、插同一个网口的机器，用同样的账号试着登录。这两步看着不起眼，却是整场排查里性价比最高的动作——因为“无法验证登录信息”这个提示是客户端给出的笼统结论，它不会告诉你到底是 DNS 解析失败、TLS 握手被拒、证书不受信任，还是账号密码真的错了。只有先做一个横向对照，才能把故障范围从“软件问题”缩小到“这台机器的环境问题”，或者反过来锁定为“账号与订阅层面的问题”。

1.2 一次登录点击背后发生的五件事

很多人把“登录”理解成“把账号密码发出去然后等结果”，实际上这个过程至少有五道关卡，任何一道断了都会以同一个红叉收场。第一关是域名解析，客户端要把服务域名翻译成 IP 地址；第二关是 TCP 连接，要能跟对端 443 端口握上手；第三关是 TLS 握手，双方要协商加密套件、交换证书、验证证书链是否可信；第四关才是身份认证，把凭据换成一张有有效期的令牌；第五关是令牌落地，把令牌和凭据缓存到本地的安全存储里，供后续调用在线服务时反复使用。

这五关里，前四关任何一关失败，用户看到的都是“无法验证登录信息”。而第五关失败的表现更隐蔽——第一次登录好像成功了，过几分钟再点分享或者加载底图，又开始报错。所以排错的核心思路不是盯着报错文案猜，而是按这五关的顺序一级一级往下测，测到哪一级断掉，问题就锁在哪一级。我在后面章节里给出的所有命令，本质上都是在给这五关做“体检”。

1.3 为什么它偏爱在线资源而不是本地数据

有读者会问，既然网络断了，为什么本地数据还能用？因为本地数据和在线资源走的是两套完全独立的路径。读本地 shapefile、地理数据库、栅格影像，走的是文件系统和数据库驱动，跟网络栈一点关系都没有；而在线底图、地理编码、路径分析、协作共享，全部依赖对在线服务的 API 调用，本质上是一次次带令牌的 HTTPS 请求。两者的分界线非常清晰，这也解释了为什么“能打开旧工程但看不到底图”是一个极具诊断价值的现象——它几乎等价于告诉你：软件本体没问题，网络或身份链路有问题。

2. 排查的整体思路：先分叉，再收敛

2.1 三分法定位：环境、凭据、信任链

我把所有可能的原因粗暴地归成三类，每次排查都从这三类里做排除法。第一类是环境类，包含 DNS、路由、出口网关、防火墙白名单、端口封禁、系统时间偏差，特点是“跟账号无关，换谁来登录都失败”。第二类是凭据类，包含账号密码错误、密码已过期、订阅未分配许可、多因素认证未完成、Windows 凭据管理器里存着旧密码，特点是“只有特定账号失败，换个人登录就好”。第三类是信任链类，包含根证书缺失、中间证书未被下发、企业网关做了证书换发、系统禁用了 TLS 1.2、证书吊销列表查不通，特点是“浏览器可能也报证书错误，但有时候浏览器能过、客户端过不了”。

这三类故障的排查顺序我一般固定为环境 → 信任链 → 凭据。理由很实在：环境和信任链是“机器级”的问题，一旦确认有问题，修一次所有账号都受益；凭据是“人级”的问题，放到最后查，可以避免一上来就折腾别人的密码，既浪费时间又容易惹人不快。

2.2 我用的最小验证工具集

我不建议一上来就装抓包工具，那玩意儿信息量大但噪声也大，容易把人带偏。真正好用的是系统里自带的那几样：ping和nslookup看解析，Test-NetConnection看端口，curl看完整的 HTTP 响应，openssl s_client或浏览器看证书链，certutil做证书链验证，cmdkey看凭据缓存。这套东西的好处是每一条的输出都足够“干净”，能直接回答一个是非问题。

# 解析是否正常 nslookup www.arcgis.com # 443 端口是否可达（Windows PowerShell） Test-NetConnection www.arcgis.com -Port 443 # 看完整的 TLS 握手与 HTTP 响应头 curl -v --max-time 15 https://www.arcgis.com/sharing/rest/info?f=json

curl -v这条尤其值得推荐，它的输出里把 DNS 解析、TCP 连接、TLS 握手、证书校验、HTTP 状态码全部按顺序列出来了。你只要看它卡在哪一段，问题范围立刻缩窄一大半。我现在带新人，第一条要求就是“先跑一遍 curl -v，把输出贴出来再说别的”。

2.3 一个容易忽略的前提：分清许可模式

在动手之前必须先问清楚一件事：这套环境用的是命名用户许可还是单机许可。这两者的联网行为完全不同。命名用户许可需要定期回到在线服务做一次身份续期，通常有几十天的宽限期，一旦超期或者期间网络不通，登录状态就会失效，界面表现为红叉；单机许可靠的是本地授权文件，正常情况下不依赖在线校验，但如果同时配了在线账号用于访问底图，那就是“许可能用、在线资源不能用”的混合状态。

那台机器的实际情况就是命名用户许可，而且宽限期已经过去了——这解释了为什么用户是“昨天还好好的，今天一开机就红叉”。很多人会误以为是网络突然断了，其实是宽限期到期，客户端被强制要求重新验证，而重新验证这条路恰好又被环境问题堵住了。两件事叠在一起，才显得特别棘手。所以我的经验是：先确认许可模式和宽限期状态，再谈网络，顺序反了会白忙半天。

3. 核心细节拆解：六个高频故障点

3.1 系统时间与证书有效期，最廉价也最容易翻车的一项

TLS 证书校验有一个硬性前提：客户端本地时间必须落在证书的有效期区间内。系统时间只要偏出几分钟，证书校验就会直接判定失败，而失败信息在客户端里被统一包装成“无法验证登录信息”。这一项的排查成本极低，但我在实际工作中遇到的频率高得离谱，尤其是长期不关机、靠休眠唤醒的办公机，以及虚拟化环境里被快照回滚过的虚拟机——时间能偏出几个小时甚至几天。

# Windows 下查看并强制同步时间 w32tm /query /status w32tm /resync

排查时不要只看任务栏右下角那个时间，那个精度只到分钟，要看带秒的完整时间，并且跟一个可靠的时间源比对。我通常会让用户打开浏览器随便访问一个带证书的站点，如果浏览器也提示“您的时钟慢了/快了”，那基本就实锤了。修完时间之后一定要重启客户端，因为很多进程在启动时就把时间相关的状态缓存住了，不重启还是老样子。

注意：域环境里时间同步通常由域控统一推送，如果发现某台机器时间持续跑偏，别只改时间，要查它的时间源配置，否则过几天又偏回去。

3.2 根证书与中间证书链不完整，企业环境的重灾区

证书链验证的逻辑是：服务端出示自己的站点证书，客户端沿着签发关系一路往上找，直到找到一个自己信任的根证书为止。中间任何一环缺失，验证就失败。问题在于，服务端有时只下发站点证书，不下发中间证书，浏览器足够聪明，会自己去补全或者缓存，但客户端库不一定有这个能力。这种情况下会出现一个非常迷惑人的现象：浏览器打开同一个站点完全正常，ArcGIS 客户端却报错。

另一个更常见的变体是企业网络出口做了内容检查，把原本的证书换成了自己签发的证书，而这张自签根证书只装在了部分机器的信任库里。表现同样是“浏览器能过、客户端过不了”，因为浏览器和客户端读取的信任库范围不完全一致。排查方法是在客户端机器上直接看握手过程中拿到的证书链：

openssl s_client -connect www.arcgis.com:443 -servername www.arcgis.com -showcerts

输出的最后会有一段Verify return code，如果显示unable to get local issuer certificate或者self signed certificate in certificate chain，方向就明确了。修复办法是把缺失的根证书或中间证书导入到“受信任的根证书颁发机构”或“中间证书颁发机构”存储区，导入之后必须重启客户端进程，否则不会生效。这里有个小细节：导入时一定要选对存储位置，导到“个人”里是没用的，很多人卡在这一步。

3.3 TLS 版本与加密套件老化，旧机器上的隐雷

服务端的安全策略一直在收紧，早年还允许的低版本协议逐渐被关闭。如果客户端所在的系统版本较老，或者被人为通过注册表调整过安全协议开关，就可能出现“TCP 连得上、TLS 握不上”的情况。curl -v在这种场景下的输出非常有辨识度：你能看到Connected to ...成功了，然后紧接着一行SSL/TLS handshake failure或者wrong version number，后面的 HTTP 请求根本没发出去。

排查时先确认系统层面允许的协议版本，再确认客户端实际协商出来的版本。Windows 上这部分配置在注册表的SCHANNEL分支下，不同系统版本的默认值差异很大，有些被安全加固过的镜像会把低版本协议全关掉，结果连正常的高版本也被牵连。我的做法是先把客户端 TLS 版本显式固定到 1.2 以上再试一次，能过就说明是协商问题，然后再回头去查系统配置为什么没协商成功。

提示：改注册表之前一定先导出备份。安全协议相关的键值改错了，影响的是整台机器的所有网络访问，不只是这一个软件。

3.4 企业网络出口的拦截与白名单，最不透明的一层

这一类问题最让人抓狂，因为它完全不在你的控制范围内。企业网络为了做审计和管控，通常会在出口部署过滤设备，对 HTTPS 流量做类别识别或者域名白名单。如果在线服务的域名没有被加入放行名单，请求就会在出口被静默丢弃或者重置，客户端等不到响应，超时之后报“无法验证登录信息”。

识别的关键特征是“时好时坏”和“换网络就好”。同一条命令，在公司网络里超时，切到手机热点立刻通；或者早上能通，下午集体断——这基本就是策略调整或者出口设备负载导致的行为。这种情况下再怎么折腾客户端都是白费力气，正确的动作是把域名、端口、用途整理成一份清单，交给负责网络出口的同事去核对放行策略。

我一般会准备这样一份最小的连通性清单，方便对面快速核对：

最后一行特别容易被漏掉。证书校验过程中，客户端会去查这张证书是否已被吊销，如果这个查询请求被拦了，客户端要么等超时（表现为登录转很久），要么直接判定验证失败。这类问题的迷惑性在于“有时候能过”，因为查询结果会被缓存一段时间，缓存过期就又不行了。

3.5 系统凭据缓存与残留登录态，改了密码也不管用

Windows 有一个凭据管理器，用来存放各种应用的账号密码。GIS 客户端登录成功后，通常会把凭据或者刷新令牌存在这里。如果用户改过密码，或者管理员重置过账号，而缓存里还留着旧的那份，客户端就会拿着旧凭据反复去请求，被拒之后报“无法验证登录信息”。用户坚信自己输的是新密码，因为他根本没机会输——客户端压根没弹输入框，直接用了缓存。

# 列出当前用户保存的所有凭据 cmdkey /list # 删除指定的凭据缓存（名称按实际列出结果填写） cmdkey /delete:"目标凭据名称"

排查这类问题的动作很直接：先把缓存清干净，再重新登录，让客户端老老实实弹一次输入框。除了系统凭据管理器，客户端自己也会在本地应用数据目录下留存令牌文件和会话状态，清理时要把这几处一起处理，只清一处往往还是老样子。我通常的做法是先退出客户端，清理缓存，再重启，然后故意输错一次密码看它是否正常报错——如果输错密码也报“无法验证登录信息”这种笼统提示，说明它根本没走到验证那一步，问题还在前三关。

注意：清理缓存前先跟用户确认，有些环境里缓存着多个系统的共享凭据，删错了会牵连别的应用。

3.6 客户端配置与门户地址指向，改过环境之后遗症

如果这套环境曾经连过自建的门户站点，客户端配置里就会记住那个地址。后来门户迁走了、域名换了、或者这台机器被挪到了另一个网段，客户端还在往旧地址发请求，当然连不上。这种故障的隐蔽之处在于报错文案完全一样，但每次重新安装或者换用户配置都能“好一阵子”，过几天又犯。

检查方法是进入客户端的账户或许可设置页面，确认当前指向的服务地址是不是预期的那个，再看连接测试是否通过。如果环境里同时存在多个站点，一定要把“活动门户”设置明确下来，不要让它自动猜测。我在实际项目里见过最离谱的一次，是测试环境的配置被镜像进了生产机器，全组人对着“无法验证登录信息”查了两天网络，最后发现只是地址指错了地方。

4. 完整实操：从零到连通的复现流程

4.1 第 0 步：建立可对比的基线

任何时候都先建基线，这是我这些年最坚持的一条。具体做法是找一台确定正常的机器，在同样的网络条件下把下面这几条命令跑一遍，把输出存下来当参照。没有基线，你看到一堆报错也不知道哪个是“正常就会有的”。基线里至少要包含：域名解析结果、443 端口连通性、curl -v的完整输出、证书链信息、系统时间偏差。

我这次的基线是在一台同网段的正常机器上取的，结果是解析正常、443 可达、curl在 300 毫秒内返回 200、证书链完整、时间偏差 0.4 秒。有了这组数据，出问题那台机器的任何异常都会显得格外突出——事实上它第一条解析就失败了，返回的是内网某个不可达的地址，这在基线对比之下几乎是一眼可见。

4.2 第 1 步：网络层通不通

从那台故障机开始，逐条往下测。第一条nslookup就出问题了：域名被解析到了一个内网地址段，而基线机上解析出来的是公网地址。追问之下才知道，这台机器换过办公位，hosts文件里还留着早年做测试时写死的解析记录。

# Windows 下查看 hosts 文件 type C:\Windows\System32\drivers\etc\hosts

清理掉那几行过期记录之后，解析恢复正常。但 443 端口仍然不通，Test-NetConnection返回TcpTestSucceeded : False。这说明还有第二层问题。继续往上查，发现这台机器的浏览器配置里，网络出口设置还指向一个早就下线的网关地址——这个配置是从旧办公位的账户漫游过来的，用户完全不知情。把出口设置改为自动检测之后，443 端口通了，curl能拿到响应。

到这里，前两关过了。这段经历值得多说一句：故障往往不是单一原因，而是多个小问题叠在一起。如果我只修了hosts就收工，用户重启之后还是会看到红叉，然后认为我什么都没干。所以每修一项，都要立刻重测，确认这一项真的解决了它该解决的问题。

4.3 第 2 步：握手层信不信

端口通了之后，curl -v的输出已经能走到 TLS 握手阶段，但卡在了证书校验，返回SSL certificate problem: unable to get local issuer certificate。这印证了前面 3.2 节的判断：企业出口把证书换发了，而换发用的根证书没有装在这台机器上。浏览器为什么能过？因为浏览器有自己的信任库和补全机制，对这种内网自签证书有一定容忍度，客户端就严格得多。

处理动作分三步。第一，从出口设备管理员那里拿到正确的根证书文件，不要从浏览器里“导出”那张已经被换发过的站点证书，那是终端证书，导了也没用。第二，用证书管理工具把它导入“受信任的根证书颁发机构”。

# 导入根证书到本机受信任根存储（需要管理员权限） certutil -addstore -f Root "C:\temp\enterprise-root-ca.cer" # 验证证书链是否完整 certutil -urlfetch -verify "C:\temp\enterprise-root-ca.cer"

第三，也是最多人漏掉的一步：完全退出客户端进程再重启。这类客户端在启动时就把信任库加载进内存了，不重启进程，导入的证书不会生效。我见过太多人导完证书发现还是报错，然后怀疑证书有问题，其实就是没重启。

4.4 第 3 步：凭据层对不对

证书问题解决之后，curl已经能正常返回 JSON 了，但客户端登录依然报“无法验证登录信息”。这时候方向转到凭据层。用凭据管理命令一查，果然，里面躺着两条指向旧地址的缓存记录，一条是旧的账号，一条是旧的令牌。清掉之后重新登录，客户端第一次弹出了正常的账号输入框——这个细节很重要，能弹出输入框说明它已经走到第四关了，前面三关是通的。

输入账号密码之后又遇到一个小插曲：多因素认证的验证码页面加载失败。原因是那个验证码页面走的是另一个域名，而这个域名恰好不在出口放行名单里。补上之后登录成功，右上角的红叉消失，头像正常加载，底图也刷出来了。

4.5 第 4 步：客户端层配没配

登录成功不代表收工。我接着做了两件事：一是确认活动门户地址指向正确，二是把许可状态检查一遍。这台机器因为是命名用户许可且宽限期已过，登录成功之后许可自动续期了，但如果在宽限期内没解决网络问题，有些环境会进入受限模式，需要手动点一次“重新授权”。另外，如果环境里配了多个门户，一定要把常用的那个设为活动门户，否则每次打开工程都可能弹一次选择框，用户体验很差。

还有一项容易被忽略的收尾工作：确认代理相关的系统级设置和用户级设置是一致的。有些机器上系统级走一套、浏览器走另一套，客户端读的是其中一套，结果就是命令行能通、客户端不通。这种情况下把两处统一是最省事的做法。

4.6 第 5 步：验证与回归测试

修完之后不能只看红叉消没消，要做一轮回归。我列了一个五项清单：加载一个在线底图并缩放到三个不同级别，确认瓦片都能刷出来；跑一次地理编码，确认返回结果正常；打开一个协作项目，确认能读取共享内容；退出客户端再重启，确认登录状态保持；让机器休眠再唤醒，确认网络恢复后能自动重连。

这五项里，最后一项最容易翻车。休眠唤醒之后，有些网络栈的状态没刷新，客户端还抱着旧连接不放，表现为“刚开机好好的，合盖再打开就红叉”。遇到这种情况，重启客户端基本能解决，但如果频繁发生，就要去查网卡的节能设置和网络栈的重连策略了。

5. 常见问题速查与避坑清单

5.1 一份可以直接对着查的速查表

这张表我在实际工作中反复用，覆盖了八成以上的场景。剩下两成通常是多个原因叠加，那就按第 4 章的流程从网络层往下逐级排查，别跳步。

5.2 几条踩出来的经验

第一条，永远先做横向对比再动手改。找一台正常机器、找一个正常账号，两个维度各做一次对照，故障范围立刻缩小一半。我见过太多人一上来就重装客户端，装了三遍问题还在，因为问题压根不在客户端。

第二条，一次只改一个变量。有次我同时清了缓存、导了证书、改了出口设置，问题确实解决了，但后来同样的故障再出现时，我完全不知道是哪一项起了作用，等于白干。现在我改完每一项都会立刻重测，把“这一项是否有效”记下来，既是排错也是积累。

第三条，不要相信“昨天还好好的”这句话。用户的时间感知往往不准，而且“昨天好好的”通常只说明昨天没用到在线功能。真正有价值的信息是“上一次成功加载在线底图是什么时候”，这个时间点能帮你对上系统更新、策略调整、密码过期这些事件。

第四条，把修复过程记成文档。这次这台机器涉及的三个问题——hosts 残留、出口设置漫游、根证书缺失——我全部记进了一份内部排错手册，附上命令和判断依据。后来同组另一位同事遇到几乎一样的情况，照着手册二十分钟就搞定了。排错能力的天花板不在于你会多少命令，而在于你能不能把经验沉淀成别人也能用的东西。

5.3 团队环境下的长效预防

单台机器修好只是开始，如果这个环境里有几十上百台机器，同样的问题一定会反复出现。我一般会推动三件事：第一，把根证书和必要的网络配置做进标准镜像，新机器开箱即用，不依赖个人手工配置；第二，把前面那份连通性清单固化成一条自检脚本，用户遇到红叉先自己跑一遍，把输出发给支持人员，能省掉大量来回沟通；第三，明确许可宽限期的提醒机制，别等到过期那天大家一起断网。

这三件事里，第二条的收益最直接。脚本本身很简单，无非是把解析、端口、curl、时间偏差、证书链这几项串起来，输出一份带时间戳的报告。但它把“你的机器哪里不对”这个模糊问题，变成了“第三项失败，证书链不完整”这样明确的结论。支持人员拿到报告就能直接定位，用户也不用反复描述症状。

还有一点值得提醒：在线资源的可用性不只是客户端的事，服务端侧的接口变更、鉴权策略调整也会导致集体登录失败。如果某天整个办公室的人同时出现红叉，而单个排查每条链路都正常，那大概率不是机器问题，先去看看服务状态公告，别一头扎进客户端里。我自己就浪费过两个小时，最后发现是服务侧在做维护，客户端一点毛病没有。