Lumerical许可证连接错误：从1055@空主机名到客户端配置全面排查

如果你被这行报错卡住过——Error: Could not connect to Ansys license server specified at 1055@——大概率你的 Lumerical 或者同一台机器上的其他 Ansys 产品已经停在启动界面半天了。这类许可证连接问题在 Ansys 系软件里非常高频，随便一搜就是几十个帖子，回复翻来覆去都是“重启 lmgrd”“关防火墙”“把环境变量改成 1055@localhost”。这些说法方向没错，但问题在于它们只覆盖了最常规的场景。我实际处理过几台工作站和同事电脑后发现，还有相当一部分情况是服务端一切正常、网络也通，但报错就是顽固地出现。

这篇文章想聊的就是这种“常规手段全部试过之后，问题仍然存在”的另一种解决办法：把注意力从服务端挪到客户端，沿着 Lumerical 自己读取许可证配置的路径，把那个“写坏、写旧、写重复”的1055@找出来改掉。这个方法特别适合三类人：一是从老版本独立版 Lumerical 升到 Ansys 集成版后突然开始报错的；二是一台电脑前后装过多个 Ansys 版本、配置互相覆盖的；三是已经按网上教程把服务端和防火墙折腾了一圈但毫无效果的。下面我会先把报错机制讲清楚，再把客户端所有配置来源整理成一张排查表，最后给出几条容易被忽视的坑。内容偏实操，按顺序走一遍，大概率能绕开卸载重装这种下策。

1. 先搞清楚 1055@ 这串字符到底在说什么

1.1 客户端启动时到底在连什么

要解决一个报错，先得看懂它在抱怨什么。Ansys 系的许可证体系用的是 FlexNet（也就是常说的 FlexLM），服务端有一个常驻进程 lmgrd 监听某个 TCP 端口，Ansys 系里最常见的默认端口就是 1055。客户端要连上许可证服务器，必须拿到一个“连接串”，格式是端口@主机名，比如1055@license-server。这个连接串可以通过环境变量ANSYSLMD_LICENSE_FILE指定，也可以写进软件自己的配置文件里。

Lumerical 启动时的动作，本质上就是：读取连接串 → 解析端口和主机名 → 建立 TCP 连接 → 和 lmgrd 握手 → 再找 vendor daemon 校验某个 feature 是否可用，全部通过才把图形界面拉起来。报错Could not connect发生在连接阶段，意思是软件没有成功和远端 1055 端口建立起有效会话。

这里有个细节值得注意：报错原文是specified at 1055@，@后面是空的。这说明客户端实际拿到的连接串是“1055 + 空主机名”，跟纯粹的连接超时不一样，它更像是配置层面根本没有给到一个可解析的地址。所以排查重心应该先放在配置本身，而不是一上来就对着防火墙一顿操作。理解这一点，后面找问题会快很多。

1.2 环境变量、注册表、AppData：到底谁说算了

很多人以为把环境变量改好就万事大吉，但 Lumerical 这个产品有点历史包袱。2021 年之前它是 Lumerical Inc. 独立发布的，许可证体系是自己那套基于 FlexLM 的 Lumerical License Manager；并入 Ansys 之后，许可证逐步切到 Ansys License Manager。老版本安装时会在用户目录和注册表里留下大量配置，新版本启动时又不会自动去清掉这些旧文件。于是“启动时到底读哪个配置来源”就成了一个优先级问题。

Windows 环境下，Lumerical 读取许可证连接串的来源至少包括这几层：进程环境变量里的用户变量、系统环境变量、当前用户目录下AppData\Roaming\Lumerical里的配置文件、安装目录下的 license 文件，以及注册表里残留的 Ansys/Lumerical 设置。如果其中一个来源存着旧的 server 地址，恰好又比环境变量更早被软件读到，那么你改环境变量改到天荒地老，它拿到的还是那个旧值。

这个“多来源 + 优先级”的问题，就是常规解法经常失效的根本原因。下面几节的内容，都是围绕这一个核心展开的。

2. 常规排查先做五分钟，别在这上面较劲

2.1 服务端状态与连通性确认

先说实话：不管我下面分享的思路有多冷门，服务端检查都值得先花五分钟。方向错了，后面全白费。你需要去 license 服务器那台机器上确认三件事：Ansys License Manager 服务有没有在跑、lmgrd 是否真的在监听 1055 端口、license 文件里的有效期和 feature 是否正常。Windows 上看端口监听很简单：

netstat -ano | findstr 1055

有输出说明 lmgrd 在监听。然后从出问题的客户端机器上验证 TCP 层通不通：

telnet <服务器名> 1055

telnet 能进去，说明网络层没问题。连不上，问题就出在防火墙、路由或者服务端进程三者之一。这一步做完，至少能把“服务端故障”和“客户端配置故障”分开，后面再往下查才有明确目标。

2.2 环境变量的常见坑：用户变量压过系统变量

常规环境变量检查时，很多人只看“系统属性 → 环境变量”弹窗里的系统变量，改完发现没用。我见过不止一次这种现场：系统变量里ANSYSLMD_LICENSE_FILE明明是对的，但用户变量里也有一份，偏偏写成了1055@，没有主机名的空值。Windows 的规则是用户变量优先于系统变量，两个同名变量最终生效的是用户变量那个。你改系统变量，相当于改了个寂寞。

请记住一个习惯性动作，先看最终生效值：

echo %ANSYSLMD_LICENSE_FILE%

如果输出是1055@或者干脆未定义，再用 reg query 分别查看用户、系统两层的值：

reg query "HKCU\Environment" /v ANSYSLMD_LICENSE_FILE reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v ANSYSLMD_LICENSE_FILE

HKCU 是当前用户层，HKLM 是系统全局层。把用户变量的残留清理掉，或者直接改成和系统变量一致。这一步做完，一部分人的问题就已经解决了，但如果你属于那种“环境变量正确、服务端也正常、依旧报错”的情况，请继续往下看。

3. 另一种解决办法：顺着 Lumerical 自身的配置目录挖根因

3.1 AppData 残留是怎么让 1055@ 变空的

现在回到标题里那个“另一种解决办法”。当服务端确认没问题、环境变量也统一了，但报错依然是1055@这种空主机名时，我的下一步动作是打开用户目录里的 Lumerical 配置文件夹：

dir %APPDATA%\Lumerical

这个目录下堆着各种设置、缓存和许可证相关文件。老版本 Lumerical（比如 2019a、2020a）安装时会在这里写入 license server 配置；新版 Ansys 集成版虽然不一定主动读这里，但软件迁移逻辑并不彻底，启动时仍然可能优先读到这份旧配置。

更麻烦的是，旧配置里的 server 字段可能是历史 IP、旧主机名，甚至因为卸载不干净而变成空值，软件一拼就拼出1055@。如果你看到报错末尾是一个孤零零的1055@，十有八九就是这类残留配置在作怪。

处理方式其实不复杂：先备份，再修正或删除。我会先把所有待改动的文件复制到一个 backup 文件夹，然后逐个用文本编辑器打开看内容，凡是能看到1055字样、或者和 server/license/port 相关的配置，都改成当前正确的地址。如果文件格式看不明白，就直接挪走，让软件重新生成一份干净的。删之前务必确认这些不是你的仿真工程设置文件，否则绘图习惯、材料库配置也会一起丢。

3.2 一套完整的清理操作流程

结合我自己处理过的几台机器，完整流程一般是这样：

第一步，彻底退出 Lumerical 和 Ansys License Manager 相关进程，包括任务栏托盘里的许可证管理图标。不退出的话文件被占用，改了也可能被写回。

第二步，统一修正环境变量。在系统变量里新建或修改ANSYSLMD_LICENSE_FILE，值填写1055@正确的服务器名。建议优先用机器名而不是 IP，机器名解析异常才用 IP 顶替。用户变量里如果有同名变量，删除或改成相同内容。

第三步，清理%APPDATA%\Lumerical下的许可证残留。找到旧 license server 配置，先备份，再修改或删除。

第四步，顺手检查注册表里有没有同名的异常项。用 2.2 里的 reg query 命令再看一遍，如果发现有字符串值异常，导出备份后修正。注册表操作要谨慎，但只改当前用户环境变量这一项风险很小。

第五步，重启电脑。这一步不是玄学，因为很多后台服务只在登录时读取一次环境变量，注销重进或者重启之后，才能确保所有进程拿到的都是新配置。

第六步，启动 Lumerical 验证。如果还报错，回到 2.1 的 telnet 检查，然后结合第 5 节的 lmutil 做进一步定位。

注意：清理 AppData 里的配置前，务必把整个%APPDATA%\Lumerical目录复制一份备份。虽然目标通常只是 license 配置，但有些文件同时绑定了材料库、脚本、绘图模板等个人数据，删错了恢复成本不低。

4. 另一个隐蔽的坑：hosts 解析与多网卡干扰

4.1 hosts 文件里的历史 IP

环境变量和 AppData 都处理完了，还有一种场景会让报错看起来很迷：客户端能 ping 通服务器名，但连接 1055 就是失败。这种情况我通常先去翻 hosts 文件：

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

hosts 文件里如果躺着一条旧解析，把服务器名指到一台已经不存在的机器 IP，那么 ping 看起来是通的——因为本地解析直接回了包——但实际数据包打到了错误地址，连接根本建不起来。尤其是服务器换过 IP、或者虚拟机做过快照回滚的时候，这类残留非常常见。

修正方式是把对应行删掉或注释掉，让系统走 DNS 解析，然后用 nslookup 确认目标主机名真实对应的 IP。做完之后再从客户端 telnet 1055 测一遍，通常就通了。

4.2 服务端多网卡导致端口绑错

另一处隐蔽问题是服务端不止一块网卡。现在的机器上经常有虚拟机网卡、蓝牙网卡、远程桌面虚拟网卡，Windows 下 lmgrd 启动时会绑定到操作系统认为的主网卡 IP，但这个 IP 未必和客户端解析服务器名得到的 IP 一致。于是客户端连过去的是物理网卡 IP，服务端监听的却是虚拟网卡 IP，两边单独看都正常，就是连不上。

这种现场，用服务端机器上的 lmutil 一眼就能看出来：

lmutil lmstat -c 1055@localhost -a

输出里会显示 license server 实际监听的地址。如果发现绑定地址和预期不符，最稳妥的办法是检查 license 文件的 SERVER 行，改成明确的 IP 而不是主机名，然后重启 Ansys License Manager 服务。改 license 文件前记得备份，并确认这台机器上其他 Ansys 产品都在用同一个地址。

5. 把“没连上”和“没验证过”分开：lmutil 与启动日志

5.1 lmutil 三件套：lmstat、lmdiag、lmver

处理许可证问题，我不太建议纯靠界面点来点去。Lumerical 安装目录下通常能找到 lmutil.exe，命令行工具很多时候比 GUI 管用。最常用的三条：

lmutil lmstat -c 1055@服务器名 -a

这条用来查看整个许可证体系的状态，包括服务端是否在线、vendor daemon 是否运行、哪些 feature 被检出、过期时间等。如果这条命令能正常输出，说明从当前这台客户端视角来看，1055 端口握手是成功的，问题大概率出在 Lumerical 自己读到的配置上。

lmutil lmdiag -c 1055@服务器名 -l 某个feature名

这条专门用来诊断某个 feature 为什么借不出来，比如LUMERICAL_FDTD。它能告诉你 feature 不存在、已被占满，还是宿主机的 license 文件里根本没这一项。

lmutil lmver lmutil.exe

这条用来查看客户端工具和服务端的版本协议是否匹配。Ansys 不同年份版本混装时，FlexNet 版本差异会导致握手失败，报错同样会落到“连接不上”这个大类里面。

5.2 Lumerical 日志怎么看

如果命令行工具已经证明可以正常连接，而 Lumerical 还是报1055@，那么下一步去翻它自己的启动日志。日志位置一般在%TEMP%或者%APPDATA%\Lumerical下的 logs 目录，文件名往往带日期或进程 ID。用编辑器打开，搜索1055、license、error这些关键词，通常能看到它实际尝试连接的地址字符串和失败原因。

这一步的意义在于：把“软件实际在连什么”和“我们以为它在连什么”对照起来。很多时候现场就是这么破的——你以为它在读环境变量，其实它在读 AppData 里的旧配置；你以为它在连生产服务器，其实它的 hosts 解析早就指向了一台不存在的机器。

6. 常见问题与避坑实录

6.1 问题速查表

6.2 几个真实案例复盘

先说印象最深的。组里一台工作站装过 Lumerical 2019a 独立版，后来又装了 Ansys 2023 R1 集成版，环境变量和服务端我查了两轮都没问题，但每次启动就报1055@。最后我在%APPDATA%\Lumerical里找到旧版设置文件，里面写的 license server 还是几年前的测试 IP。把文件备份后删掉，让软件重新生成配置，问题才解除。这个事的教训是：升级软件不等于迁移配置，旧文件要当一等嫌疑犯来排查。

第二个案例和 hosts 有关。一台虚拟测试机从快照回滚后 IP 变了，但 hosts 里还留着旧 IP 的映射。客户端解析服务器名被指到一个不存在的地址，报错自然是连接失败。当时 ping 能通让人误判了很久，后来把 hosts 里那一行注释掉才恢复正常。

第三个案例是用户变量压系统变量。同事的系统变量已经是正确的1055@license-server，但用户变量里残留着一个安装器写入的空值1055@。他每次都去改系统变量，重启后看还是老报错。这个问题的迷惑性在于，表面上看该改的都改了，实际上真正生效的那个值藏在另一个位置。

6.3 最后提醒两件事

第一，不要把服务器名写成 localhost 了事。如果 Lumerical 装的位置和 license 服务器不是同一台机器，localhost 指回自己，无论如何都连不上。只有单机使用、license 服务就在本机时，1055@localhost才是有效值。

第二，清理完所有配置后，如果服务端之前已经运行了很久，建议把 Ansys License Manager 服务也重启一遍，让 lmgrd 重新读取许可证文件。有时候客户端这边焕然一新，服务端却还带着旧状态，两边不同步，照样报连接错误。

从我处理这些台式机、工作站和虚拟机的经历看，Ansys 系这类Could not connect报错，八成以上不是服务端真的挂了，而是客户端多个配置来源里某个不起眼的坏值在捣乱。处理顺序对了，很多问题其实五分钟就能解决。最后再分享一个小习惯：遇到许可证报错，我永远先敲echo %ANSYSLMD_LICENSE_FILE%确认当前进程实际拿到的是什么，再用 lmutil 验证服务端，最后才去翻 AppData。按这个顺序走，基本不会在错误方向上浪费太多时间。希望这条路径对你有用，少走点弯路。