不需要手动更改iNode客户端的认证服务器IP‌，前提是部署了虚拟IP（VIP）方案。冷备切换后，VIP漂移至备机，iNode客户端仍用同一地址认证，无需改动。

关键前提：是否配置了VIP

• ‌已配置VIP（推荐）‌：主备机共用同一虚拟IP，交换机Portal和RADIUS均指向VIP。主服务器故障后，VIP自动漂移至备机，客户端无感知，无需改IP。
• ‌未配置VIP‌：主服务器宕机后，需手动将接入设备（交换机/AC）上的Portal服务器和RADIUS服务器地址改为备机IP，并确保iNode客户端指向的服务器地址同步更新。‌‌
  

iMC7.0 EIA双机冷备（非热备）场景，iNode 做 Portal 认证：主 iMC 服务器中断，iNode 客户端本身不会自动切换到备服务器 IP，需要区分「RADIUS 侧接入设备」和「iNode 客户端 Portal Web 交互」两部分，二者行为不一样。

冷备方案说明：冷备是两套独立 iMC，定期手工同步数据库，无实时业务自动倒换，没有虚拟 IP；主服务器宕机需要人工操作：把业务切到备 iMC。

1、RADIUS 认证部分（交换机 / AC 接入设备）

接入设备（交换机、AC）RADIUS 方案配置主、备 RADIUS 服务器 IP：

✅这一层：接入设备会自动探测主服务器不可达，自动切 secondary 备服务器做 RADIUS 认证，这部分不需要动 iNode 客户端。

2、iNode‑Portal 客户端交互（重点，你的问题核心）

Portal 分为两部分：RADIUS 报文（交换机和 iMC 之间） + Portal Web 页面 / 报文（iNode 客户端直接访问 iMC 的 Portal Web 服务）

• iNode 的 Portal 连接配置里面写的是主 iMC 的 Portal Web IP / 域名；
• 主 iMC 整机中断后：RADIUS 层面交换机可以切备，但iNode 客户端访问 Portal Web 服务依旧指向已经宕机的主服务器 IP，Web 页面打不开，iNode 无法发起 Portal 认证； 👉 iNode 客户端不会自动识别、自动切换备服务器 IP，需要人为修改 iNode 连接里面的 Portal 服务器地址为备 iMC IP。

对比 802.1X：iNode‑802.1X 场景，客户端不需要访问 iMC 的 Web 服务，全部 EAP 报文交给交换机，交换机 RADIUS 自动切 secondary，802.1X 不需要改 iNode 配置；但是 Portal 不一样，客户端直连 Portal Web 服务，冷备无虚拟 IP 就无法自动切换。

3、冷备下 Portal 的两种规避手段

方案 A（推荐，消除客户端改 IP 操作）：使用 DNS 域名方式

iNode Portal 连接里面填写域名，不要写死 IP。故障时，运维修改 DNS 解析，把域名从主 iMC IP 修改指向备 iMC IP；iNode 重新解析域名访问备服务器，不需要每台终端修改 iNode 连接配置。

前提：主备 iMC 的 Portal 页面、证书、服务配置完全一致；冷备要提前把主的 Portal 页面文件、证书同步到备机。

方案 B：iNode 管理中心批量下发双服务器配置

iNode 管理中心定制 Portal 连接，预置主、备两套服务器配置；故障后推送新策略给终端，终端加载备服务器的 Portal 连接配置。

4、冷备切换完整操作流程（主 iMC 中断）

1. 数据库确认：确认主 iMC 最后一次备份数据库已经恢复导入备 iMC，用户、接入设备、EIA 策略数据完整；
2. 网络侧：接入设备 RADIUS 自动切换 secondary 备 iMC；
3. Portal Web 访问：
   • 如果用 DNS：修改 DNS 域名解析指向备 iMC；
   • 如果写死 IP：所有 iNode 客户端手动修改 Portal 连接服务器 IP 为备 iMC；
4. 验证：iNode 发起 Portal 认证，RADIUS 报文走备 iMC，Portal 页面访问备 iMC，认证正常；
5. 注意：已经在线 Portal 用户，主 iMC 宕机后，因为无实时会话同步，在线用户会超时下线，需要重新认证上线（冷备固有限制，热备才支持会话同步）。

5、关键区分对比（冷备）

表格

冷备是机器IP一样的，主的有问题，备的开机通电插网线

热别是自动的，可以是虚拟地址