如果你做过仿真、数据处理或者科研计算大概率对MATLAB的网络许可证并不陌生。我身边不少同事第一次遇到License Manager Error -31这个报错时第一反应都是“许可证是不是过期了”“服务器是不是挂了”结果重启服务、重新激活全试了一遍问题依旧。最后排查才发现客户端和许可证服务器的系统时钟整整差了8个小时而问题根源就出在“时区不一致”上。这背后其实是一整套 FlexLM 时间校验机制在起作用远比表面上一个报错码复杂。这篇文章不只是做报错速查我会把时间校验原理、时区差异为什么能触发 -31、Windows 和 Linux 下如何修复、以及长期维护时怎么避免再踩坑一起讲清楚。无论你是刚接触 MATLAB 网络许可证的新手还是已经维护了一段时间、正在为偶发报错头疼的工程师这篇内容都值得完整看一遍。1. 手把手排查时区问题如何触发MATLAB的-31报错1.1 网络许可证的“签到”逻辑要理解 -31先得知道 MATLAB 网络许可证是怎么工作的。MATLAB 授权服务器上运行着一个许可证守护进程它管理着整套许可证资源。客户端机器上的 MATLAB 启动时会通过环境变量或者许可证文件里的配置找到这台服务器然后申请一个“许可证租约”。这个过程很像去健身房刷会员卡你的手环信息客户端时间戳和门店系统许可证服务器之间必须能对得上。如果手环显示的时间和门店系统差太多前台就有理由怀疑这张卡有问题拒绝你入场。FlexLM 的做法类似客户端向服务器发起许可请求时会把本机的系统时间一并带过去服务器把自己的当前时间和客户端时间进行比较。一旦差值超过某个阈值服务器就认为客户端时钟异常拒绝签发许可MATLAB 客户端随即报出License Manager Error -31。这里的“阈值”通常被描述为 5 分钟也就是 300 秒。不同版本、不同厂商的 FlexNet 配置可能略有差异但默认逻辑基本一致客户端和服务器的时间差必须控制在一个很小范围内否则授权不可用。1.2 时区差异到底错在哪很多人的第一直觉是时区不同本地时间显示差好几个小时报错理所当然。但严格来说计算机系统时间分两层一层是硬件级、UTC 基准的绝对时刻另一层是时区偏移。也就是说一台机器可以设置为东八区本地时间显示另一台设置为 UTC 标准时间显示只要两台机器各自都知道自己的 UTC 基准是多少它们的“绝对时刻”是可以完全一致的。理论上FlexLM 校验的是绝对时刻偏差而不是你眼睛看到的本地时间差异。单纯“时区显示不同”但两台主机都正确配置了时区、并且通过 NTP 同步到了同一个 UTC 基准是不应该报 -31 的。真正坑人的场景往往是这样的服务器设成了东八区客户端管理员图省事手动改了系统时间而没有设置正确的时区或者两台机器分别用了不同时区但硬件时钟存放的基准不一致导致它们各自的 UTC 绝对时刻本身就差了好几个小时。所以排查时最忌讳只看date命令输出的本地时间。正确的做法是看date -u也就是 UTC 时间。如果两台机器date -u输出的差值小于 300 秒时间校验就能过如果差值很大那不管本地时间看起来多“合理”MATLAB 都会认为你的系统时钟错了。1.3 官方允许的“5分钟偏差”到底是什么300 秒的容差听起来很宽松但实际运维里非常容易被突破。我遇到过的情况是某内网环境不能访问外网没有 NTP 同步服务器和客户端运行了几个月后各自主板上的硬件时钟漂移了几分钟于是一台机器显示 10:02另一台显示 10:08MATLAB 直接报 -31。这种情况和时区无关只是纯粹的时间不同步。还有一种更隐蔽的情况客户端的时区设置错了。比如服务器在东八区客户端在 UTC但客户端管理员手动把本地时间调成了和服务器一样的本地时间而不是改时区。这样一来客户端的 UTC 基准其实变成了“东八区时间”本地却显示成 UTC结果就是 UTC 绝对时刻相差了 8 小时。表面看两台机器date显示的时间一样但date -u立刻露馅。理解了这一层后续所有修复动作就会很清晰不是单纯“把两个时区改成一样”就完事而是要让两台机器在 UTC 绝对时刻上保持一致。2. 读懂License错误文本-31与-95、-13的区别和联系2.1 -31报错的典型文本和隐藏含义启动 MATLAB 时如果许可证校验失败通常会弹出一个对话框或同时在命令行输出错误码。License Manager Error -31的经典描述长这样License Manager Error -31 MATLAB is unable to connect to the License Manager. System clock is set incorrectly. Check that the date, time, and time zone are correct.这段文本最坑人的地方在于它把“date, time, and time zone”并列在一起。很多人只看到 date 和 time就跑去把客户端时间手动调成和服务器一致却忽略了 time zone 也是一个独立变量。如果客户端时区本来就不对你手动把时间调成服务器显示值过几天重启之后又会漂移回来或者因为网络时间协议自动同步时间又被“纠正”回错误的时区对应的正确绝对时刻于是再次报 -31。另一些情况下文本可能只写“The time difference between the license server and system clock is too large.”没有提到时区。这时更要警惕到底是服务器的时钟漂了还是客户端的时钟漂了又或者两边的时区都正常但硬件时钟基准不同。只看报错文本无法回答这些问题必须看具体时间数据。2.2 与-95、-13的快速区分很多时候网络许可证报错不只有 -31。运维现场经常把 -31、-95、-13 混在一起讨论但它们的原因完全不同修复手段也南辕北辙。错误码常见提示核心原因解决方向-31System clock is set incorrectly客户端与服务器时间差超过阈值统一时区、同步时间-95Cannot connect to license server网络不通、服务器未启动、端口被防火墙拦截检查网络、lmgrd 进程、端口-13This feature is not available许可证功能不可用或未启动检查 feature 名称、许可证文件内容-39Invalid host主机名/主机ID与许可证不匹配检查 license.dat 的 HOSTID如果你是第一次排查先从错误码入手。如果是 -95大概率是网络链路问题别浪费时间调时区。如果是 -31再进入时间排查流程。如果同时出现多个错误码比如先 -95 再 -31那可能是许可证服务本身异常连带影响了时间校验流程。2.3 一个快速判断口诀我个人总结了一个非常简单的判断方法适用于绝大多数 -31 现场在两台机器上分别执行同样的命令比较输出。date -u date %sdate -u显示的是 UTC 时间date %s显示的是 Unix 时间戳。只要这两台机器的date %s输出相差小于 300时间本身没问题如果相差很大那就先不要去动许可证文件先把时间问题解决。这条经验帮我省下了无数次无效重启。3. Windows和Linux客户端时钟修复实操3.1 Windows客户端的时区与时间同步Windows 客户端是 MATLAB 最常见的运行环境处理起来也最直接。先打开“设置 - 时间与语言 - 日期和时间”把“自动设置时间”和“自动设置时区”打开。如果公司网络允许访问互联网时间服务器这一步通常就够了。但如果你的办公网是内网、不允许出公网或者系统里时间源被组策略锁死那就需要用命令行。查看当前时区tzutil /g设置时区例如东八区需要管理员权限tzutil /s 你就是东八区对应的时区ID这里我不直接写死某个时区 ID因为不同语言版本的系统时区 ID 显示方式可能不同。最稳妥的办法是先运行tzutil /l列出全部时区从列表里找到你需要的东八区项复制它的 ID 再执行。注意tzutil改的是时区设置不会自动把时间同步到这个时区的正确时刻所以之后还要同步一次时间。强制同步时间net start w32time w32tm /resync实测中w32tm /resync有时会返回“没有可用时间源”这时候要确认 Windows Time 服务是否在运行以及当前时间源配置是否正确。如果内网有 NTP 服务器可以用下面的命令手动指定w32tm /config /manualpeerlist:你的NTP服务器地址 /syncfromflags:manual /update w32tm /resync改完时区、同步完时间建议再执行一次date /t和w32tm /stripchart /computer:你的许可证服务器 /samples:1做对比确认客户端和服务器的时间差已经小于 5 分钟再启动 MATLAB。3.2 Linux客户端的时区与时间同步Linux 下的 MATLAB 客户端同样会遇到 -31而且命令更集中。现代 Linux 系统一般使用 systemd一条命令就能看到所有时间状态timedatectl输出里会明确显示本地时间、UTC 时间、时区 ID以及 NTP 是否启用。这是排查时最好的起点。修改时区同样用占位符代替具体时区 ID避免不同发行版和不同语言环境的差异sudo timedatectl set-timezone 你的时区ID之后确认系统时间和日期是同步的sudo timedatectl set-ntp true如果使用的是 chrony 作为 NTP 客户端还可以手动快速同步一步到位sudo chronyc makestep对于没有 systemd 的旧系统可以使用传统命令先把硬件时钟设为 UTCsudo ln -sf /usr/share/zoneinfo/你的时区ID /etc/localtime sudo hwclock --systohc --utc然后安装并使用 ntpdate 手动同步sudo ntpdate 你的NTP服务器地址需要注意的是部分云服务器默认没有安装 ntpdate而且系统里可能同时存在 chrony 和 systemd-timesyncd多个时间同步服务会互相抢时间源。排查时如果发现时间一直在跳先看是不是有两个 NTP 服务同时在工作。3.3 虚拟机和容器的额外坑我在容器环境里踩过的坑比物理机多得多。Docker 容器默认是 UTC 时区而宿主机往往是东八区。如果 MATLAB 跑在容器里而许可证服务器跑在宿主机上两边date -u其实是一致的因为容器共享宿主机的内核时钟通常不会触发 -31。但如果你在容器里运行date看到的时间和宿主机差 8 小时很多人就会手贱去容器里手动改时间结果反而把容器内的时钟偏差改乱了。更稳的容器做法是不要在容器启动后手动改时间而是把宿主机的时区文件挂载进去或者调整环境变量TZ。如果是定制镜像预先安装 tzdata 并设置时区就可以了。虚拟机也有类似问题尤其是从模板克隆出来的虚拟机如果模板时钟本身就不准克隆后所有节点的系统时间会一起偏移这时候光改时区没用必须对每个节点单独做时间同步。4. 许可证服务器端检查与长期时间治理4.1 lmstat与lmdiag快速体检修复客户端之前先确认许可证服务器自己是否正常。FlexLM 自带了一套诊断命令其中最常用的是lmstat。在服务器上执行lmstat -a -c license.dat输出里能看到lmgrd是否在运行、各功能feature的状态、当前有多少用户在占用等。如果lmstat本身都连不上服务器那就不是时间问题而是服务没起来。进一步诊断具体功能可以用lmdiag -c license.dat -l matlab这段命令会尝试真实地去服务器申请一个许可证如果时间校验失败它会报出具体错误原因比盲目重启服务有效得多。我在实际运维里遇到过好几次服务器端时间漂移但lmstat显示一切正常只有跑lmdiag才发现是时间问题。所以每次排查 -31我都会把lmdiag作为第二步而不是直接去改客户端。4.2 调整FlexLM时间容忍度的进阶选项有些运维工程师问我能不能把 FlexLM 的时钟容忍度调大一点比如从默认 5 分钟改成 1 小时这样时间漂移就不容易报错了。理论上 FlexLM 配置文件里确实有和时钟超时相关的参数可以通过lmf.conf之类的文件去设置。但这里我必须提醒一句不同 FlexNet 版本的参数名差异很大而且厂商未必支持这个调整生产环境贸然修改很可能导致其他更隐蔽的授权问题。我的建议是把调大容差当成一个“应急实验”而不是长期方案。真正该做的是把时间同步做好。时间同步做到位之后容差 5 分钟还是 1 小时根本不重要因为你永远不会触发它。4.3 长期方案统一NTP时间基线排查解决一次 -31 很容易难的是以后不再犯。长期方案只有一个核心让所有涉及许可证校验的主机都使用同一个 NTP 时间基线。具体落地可以分三步。第一步在内网搭一台内部 NTP 服务器让它同步上游时间源再向下分发。如果内网完全隔离就指定某几台稳定机器作为基准其他节点向它们同步。第二步在这台 NTP 服务器上同时给许可证服务器和所有 MATLAB 客户端配置自动同步。Windows 用w32tmLinux 用 chrony 或 systemd-timesyncd。第三步写一个巡检脚本定期比较各节点date %s与基准节点的差值超过 60 秒就告警把问题消灭在用户报错之前。时区本身怎么设置反而可以按业务习惯来。服务器用统一的 UTC 便于日志对比客户端用东八区方便本地用户查看都没有问题。关键不是大家显示的时间字符串一样而是 UTC 绝对时刻一致。5. 避坑经验故障排查路线图与常见问答5.1 一套可以抄作业的排查路线以下是我自己整理的一套排查路线适合每次遇到 -31 时按顺序执行避免东一榔头西一棒子。先记录完整报错文本确认确实是 -31而不是 -95 或 -13。在客户端和许可证服务器分别执行date -u和date %s拿到两个时间戳。计算两个时间戳的差值。如果大于 300 秒进入第 4 步如果小于 300 秒进入第 5 步。检查两端时区设置。Windows 用tzutil /gLinux 用timedatectl。把出错端的时区改为正确的东八区或 UTC然后重新同步时间再回到第 3 步确认。如果时间差已经小于 300 秒但仍然报 -31检查系统里是否有多个时间同步服务冲突或者检查许可证服务器上是否有可疑的 VENDOR daemon 异常。此时用lmdiag -c license.dat -l matlab做一次真实诊断。确认许可证服务正常后重启 MATLAB 客户端。不要只重启客户端而忽略服务器端。如果服务器端异常lmstat -a里通常能看到线索。这套路线我用了很久百分之九十的 -31 都能在 20 分钟内定位。5.2 常见误区先列几个我见过最多的错误认知都是真实踩坑案例。第一个误区是“把客户端时间手动调成和服务器一样就完事”。这个操作只骗过了人眼没有骗过 FlexLM。因为系统时间是一个绝对概念手动调完不校验时区过一晚就又会因为各种自动同步而跳回去。第二个误区是“两台机器时区改成一样就安全了”。时区一致只是第一步如果两台机器都没有 NTP 同步硬件时钟漂移照样会让它们越过 300 秒的容差线。时区一致不等于时间同步。第三个误区是“只有客户端时间有问题”。服务器时间漂移的案例在真实环境里很常见尤其是长期不关机的物理服务器。排查时不要只盯着客户端两边都要看。第四个误区是“改完时间后不用重启 MATLAB”。MATLAB 启动时才去申请许可证启动过程中读取的时钟状态会被缓存旧的错误会话可能一直保留到 GUI 关闭。改完时间后最好完整退出启动中的 MATLAB 进程再重新打开。5.3 问题速查表我把现场最常见的几个场景整理成一张速查表仅供参考和快速定位。现象可能原因处理方向本地时间显示只差几分钟但报 -31时区错误导致 UTC 偏移或 NTP 未同步前的漂移查看date -u修正时区重新同步时区相同依然报 -31两端未同步硬件时钟漂移配置 NTP重启许可证服务后重试同一集群中部分节点报错部分正常被报错节点的 VM/容器时钟漂移或模板克隆文件残留对单个故障节点单独同步并检查 NTP 服务改用本地许可证后正常用网络许可证报 -31本地许可不校验时间网络许可校验回到了时区与同步排查主流程报 -31 但同时伴随 -95许可证服务本身异常或网络端口问题先解决服务和网络再处理时间5.4 几个运维上的小建议最后说几点个人经验不涉及具体配置但对长期维护很有帮助。第一别只看报错码。MATLAB 的许可证错误码是高度“汇聚”的同一个 -31 可能对应多种根因必须结合时间戳、网络、服务状态综合判断。第二把时间同步这件事写进交付 checklist。不管是给新员工培训还是给新机器上线都明确一条启用 NTP设置正确的时区。第三注意办公网防火墙对 NTP 端口 123 的策略。很多内网限制了这个端口导致自动同步失败。提前找网络管理员确认能省掉后面大量隐蔽问题。第四如果有多台许可证服务器做高可用所有服务器之间的时间容差也要校验。客户端和主服务器同步了但备用服务器时间不对故障切换之后照样报 -31。我在实际工作中感受最深的一点是这种问题往往不是“技术难度高”而是“太隐蔽”。少有人会怀疑一台刚装好的服务器时区是错的也没有人每天盯着系统时间看。但只要你把时间基线统一了把排查路线固定下来这套麻烦就能彻底从日常清单里划掉。