简介：Citrix ADC（NSVPX-HyperV-13.0-47.24）是面向在 Microsoft Hyper-V 上部署应用交付控制器的虚拟设备安装包，适合需要实践负载均衡、SSL 卸载、应用防火墙与多云接入的网络工程师及运维学习者。压缩包共 6 个文件，约 510.17MB，包含 vhd 虚拟磁盘、vmcx/vmrs 虚拟机配置与状态文件、exp 导出文件及 xml 配置文件，基本覆盖 Hyper-V 导入与初始化所需组件，便于快速搭建实验环境并对照官方部署流程验证网络接口、VIP 与策略配置。已有 442 人学习，说明该版本在同类实验资料中具备一定参考度。读者可据此熟悉 NSVPX 虚拟机的导入、资源分配与基础配置，理解版本匹配对兼容性和性能的影响，并围绕负载均衡、内容优化、多租户管理等知识点开展验证，减少因环境不符造成的部署阻碍。

1. 从一台卡在启动控制台的虚机说起：NSVPX 在 Hyper-V 上要解决什么

把 Citrix ADC 的虚拟化镜像 NSVPX 部署到 Hyper-V，版本停在 13.0-47.24，这件事表面上只是点几下鼠标的活。真正动手的人会发现问题不在策略写得对不对，而在导入之后控制台黑屏、网卡认不出来、管理地址敲完重启就没了。这个组合要解决的是把四层到七层的流量调度能力从专用硬件搬进虚拟化资源池：SSL 卸载、会话保持、健康检查、内容交换，全都跑在一台虚机里，按需扩缩，不用等采购流程。适合自建机房和私有云里同时管网络与应用的那批人，尤其是预算批不下来、但业务确实需要一台正经负载均衡器的时候。接下来按版本约束、虚机落地、配置闭环、排查、验证五段讲，能抄的部分我尽量给全。

2. 版本号拆开看：13.0-47.24 在 Hyper-V 上能干什么、干不了什么

选型阶段最容易犯的错，是拿硬件设备的规格表去套虚拟化版本。硬件机器上有专门的加密协处理器和网络处理单元，包转发和 TLS 握手不占主 CPU；NSVPX 全部压在 vCPU 和内存带宽上，中间还要穿过 Hyper-V 的虚拟交换机，每个包都得走一遍分类器和扩展层。同一份配置脚本，在物理机和虚机上跑出来的性能曲线完全不是一回事，所以第一件事不是装，是算账。

2.1 虚拟化形态牺牲掉的那部分能力，以及怎么提前算清楚

硬件平台省下来的那部分开销，虚机里必须自己补。具体补在两处：一是加解密，TLS 握手、批量加密全部吃 CPU 周期；二是转发，虚拟交换机没有专用转发芯片，全靠宿主机的软件队列。所以规划时我一般不看厂商给的峰值宣传数，只做两件事：先用一颗 vCPU 压出这台宿主机上的实际包处理基准，再拿业务峰值包量去除，最后乘 1.5 倍余量。这个 1.5 不是拍脑袋，是留给突发流量和宿主机上其它虚机争抢的时间片。

TLS 要单独算一笔。握手是纯 CPU 操作，跟吞吐不是同一个维度：一个页面站点可能 QPS 高但流量小，握手压力反而比大文件下载大得多。做法是把新建连接比例估出来，用压测工具单独打一轮"只握手不传数据"的负载，看 CPU 什么时候跑满。跑满的那个连接数，才是这台虚机真实能承载的并发上限，比任何规格表都准。

功能层面，绝大部分七层能力在虚机上是齐的，真正受影响的是依赖硬件的那些：大流量压缩、某些链路层特性、以及需要专用加速卡的场景。这些在虚拟化环境里要么禁用，要么改用软件实现后性能掉一大截。判断标准很简单，看某个特性的说明书里有没有"需要特定硬件"这类限定语，有就别指望在 NSVPX 上开出来。

还有一条容易被忽略：许可。许可按吞吐分档，装完不导入的话跑在一个很低的上限上，表现出来的现象是"配置全对、压不上去"，而不是报错。这一条坑过不少人，排查时先看许可状态，再看别的。

2.2 三个前置条件：虚拟机代次、磁盘类型、网卡型号

Hyper-V 这边有三个参数在创建虚机那一刻就定死了，事后改要重建。列成表格更清楚。

代次这一条是最容易翻车的。第 2 代虚机只支持 VHDX 和 UEFI，而拿到的镜像多半是 VHD 加传统 BIOS 引导，直接挂载的结果就是启动后停在一行提示上不动。别指望转换格式能救，转换出来的 VHDX 依然是 BIOS 引导结构，第 2 代虚机照样不认。老老实实用第 1 代，磁盘挂 IDE 控制器。

磁盘用固定大小这一点，短期看不出差别，跑上两周监控就能看到。动态扩展盘在写入量增长时需要先在宿主机上分配空间，这个瞬间的 IO 延迟会直接传导到连接建立耗时上，表现出来就是 p95 曲线每隔一段时间冒一个尖。系统盘所在的存储也尽量单独放，别和日志量大的虚机挤一个卷。

网卡要分两种情况说。合成网卡性能好，走的是虚拟交换机的快速路径，但要求镜像里有对应的集成服务驱动；老版本镜像可能只带旧版网卡的驱动，启动后进控制台敲命令，只能看到一个 lo，物理网卡根本没被枚举。这种时候把网卡型号换成旧版网卡（Legacy Network Adapter）一般就能认出来，代价是走模拟路径，吞吐会低一截。先跑通再优化，顺序别反。

2.3 构建号不是装饰：配置语法与 NITRO 版本对齐

13.0 是主版本，决定 CLI 语法结构和 NITRO 的资源模型；47.24 是构建号，决定这一版修了什么、有没有引入新的默认行为。运维上要对齐三件事。

第一，台账里必须记构建号，不能只写"13.0"。变更单上贴show ns version的原始输出，出问题时能第一时间判断是不是构建差异导致的行为变化。

第二，配置文件不要跨构建号恢复。用show ns runningConfig导出的文本，在低构建号上恢复可能报语法错误，在高构建号上恢复可能静默丢掉新增字段。稳妥做法是恢复后逐条比对，或者干脆只恢复业务对象，系统级参数手工核对。

第三，NITRO 脚本里登录之后先读一次版本，做兼容分支。同一套脚本在不同构建号上跑，个别字段名或枚举值会变，硬编码的结果就是批量任务跑一半红一片。

# 登录后先核对版本、硬件抽象层与已启用特性，避免脚本在错误的目标上执行 show ns version # 输出主版本与构建号，确认是 13.0-47.24 show ns hardware # 查看 vCPU 数、内存、网卡枚举情况 show ns feature # 列出已开特性，确认 LB / SSL 是否已启用 show ns license # 确认许可带宽档位，排除"能配但跑不动"

这四条命令建议做成一个检查脚本，每次变更前先跑。show ns hardware在虚机上尤其有用，能直接看到网卡认出来几张、vCPU 给了几颗，比在 Hyper-V 管理器里猜要快。show ns feature里如果 LB 是关闭状态，后面配的虚拟服务器全部不生效，这个坑新手经常踩。

3. 从 VHD 到能登录：在 Hyper-V 上把 NSVPX 跑通的最小步骤

前面算完账，接下来是纯落地。这一段的目标很明确：虚机能启动、控制台能进、管理地址能通、能打开图形界面。四步走完再谈业务配置，跳步的结果往往是后面排查时分不清是网络问题还是配置问题。

3.1 虚拟机规格怎么定：一张参数表说清

规格没有标准答案，但有下限。低于下限的表现是配置能配、压不上去；高于下限的代价是浪费宿主机资源。给一版常用的起步配置。

系统盘这块要多说一句。虚机里扩容系统盘不是把 VHD 调大就完事，涉及分区表和挂载点，直接在 Hyper-V 里改大小然后重启，大概率得到一台起不来的机器。真需要更大空间，常见做法是加一块数据盘挂到指定挂载点，而不是动系统盘。

网卡数量也要提前想。管理口和数据口分开，是后续排查的基础：管理面出问题时，数据面还在转发，业务不中断；数据面出问题时，还能从管理口进去看。挤在一块的省事做法，在第一次故障时就会让你后悔。

3.2 PowerShell 导入 VHD 并挂载管理网卡

图形界面点也行，但参数化之后可以复用，重建虚机不用重新记一遍选项。下面这段在宿主机上以管理员身份跑。

$vmName = "ADC-VPX-01" $vhd = "D:\vhd\NSVPX-HyperV-13.0-47.24.vhd" # 镜像解压后的 VHD 绝对路径 $mgmtSw = "vSwitch-Mgmt" # 已创建的外部虚拟交换机 # 1) 建一台第 1 代虚机，先不挂盘 New-VM -Name $vmName -Generation 1 -MemoryStartupBytes 8GB -SwitchName $mgmtSw # 2) 固定 vCPU 与内存，关闭动态内存避免被宿主机回收 Set-VMProcessor -VMName $vmName -Count 4 Set-VMMemory -VMName $vmName -DynamicMemoryEnabled $false -StartupBytes 8GB # 3) 把镜像盘挂到 IDE 控制器 0 号位置，作为启动盘 Add-VMHardDiskDrive -VMName $vmName -ControllerType IDE ` -ControllerNumber 0 -ControllerLocation 0 -Path $vhd # 4) 管理网卡固定 MAC 并开启 MAC 欺骗，原因见 3.4 Set-VMNetworkAdapter -VMName $vmName -Name "Network Adapter" ` -StaticMacAddress "00155D0A1B01" -MacAddressSpoofing On Start-VM -Name $vmName

几点说明。第一步不挂盘、第二步单独挂盘，比New-VM -VHDPath一步到位更可控，因为可以显式指定 IDE 控制器和位置，避免镜像被挂到 SCSI 上导致引导失败。-ControllerType必须是 IDE，第 1 代虚机的 SCSI 控制器不能作为引导设备。

Set-VMMemory里关掉DynamicMemoryEnabled是关键。开着动态内存，宿主机在内存压力下会把虚机的内存页换出，对一台要做实时转发的设备来说，这个换出动作会直接表现为几秒钟的假死。监控上看到的是周期性无响应，然后自己恢复，很难往内存上想。

MAC 地址用00155D开头是 Hyper-V 的习惯前缀，后面自己编号。固定 MAC 的好处是后续做 DHCP 保留、ARP 绑定、上游交换机的端口安全策略时不用改配置。坏处是克隆虚机时容易连 MAC 一起复制，这条留到第 5 章细说。

3.3 控制台首配：管理地址、默认路由、DNS

虚机起来后通过 Hyper-V 管理器连控制台，默认口令登录，进的是命令行界面。第一次配管理地址必须在控制台做，因为一执行完，原来的访问方式就断了。

# 在控制台 CLI 中执行；先设配置层地址，再声明 NSIP，顺序不要反 set ns config -IPAddress 192.168.10.10 -netmask 255.255.255.0 add ns ip 192.168.10.10 255.255.255.0 -type NSIP # 默认路由只能有一条，指向上游网关 add route 0.0.0.0 0.0.0.0 192.168.10.1 # 只允许通过 HTTPS 访问管理界面，避免明文口令在网络上传输 set ns ip 192.168.10.10 -gui SECUREONLY # 配置落盘，否则重启后全部回退 save ns config

set ns config和add ns ip分开写，是因为前者改的是管理配置层的地址，后者是把地址声明成 NSIP 类型参与转发。两条命令的效果看起来一样，实际作用范围不同，只做前者的话，图形界面能开但部分功能会提示地址未就绪。

save ns config这条最容易忘。命令行里改的全部是运行配置，落在内存里，重启就没了。养成变更脚本末尾统一加这一句的习惯，比任何流程规范都管用。

配完之后用浏览器访问https://192.168.10.10，能出登录框就说明管理面通了。这一步过了再去动数据面，顺序反了的话，一旦数据面配错导致整个虚机失联，只能回控制台重来。

3.4 加数据面网卡：VLAN 标记与 MAC 欺骗开关

管理面通了之后再加数据面。两块数据网卡分别对应入口和出口，加到同一个或不同的虚拟交换机上，取决于网络规划。

# 追加两块数据网卡，挂到业务交换机上 Add-VMNetworkAdapter -VMName "ADC-VPX-01" -Name "Data-In" -SwitchName "vSwitch-Data" Add-VMNetworkAdapter -VMName "ADC-VPX-01" -Name "Data-Out" -SwitchName "vSwitch-Data" # 数据面同样要开 MAC 欺骗，否则虚拟交换机会丢弃源 MAC 不匹配的帧 Set-VMNetworkAdapter -VMName "ADC-VPX-01" -Name "Data-In" -MacAddressSpoofing On Set-VMNetworkAdapter -VMName "ADC-VPX-01" -Name "Data-Out" -MacAddressSpoofing On # 若采用虚拟交换机侧打 VLAN，用访问模式指定 Set-VMNetworkAdapterVlan -VMName "ADC-VPX-01" -VMNetworkAdapterName "Data-In" -Access -VlanId 100

MAC 欺骗这一项必须讲清楚。Hyper-V 的虚拟交换机默认做源 MAC 校验，只允许虚机发出的帧携带分配给它的那个 MAC。负载均衡设备做转发时要改写源 MAC，不关掉这个校验，帧会被直接丢弃，表现出来就是"配置全对、抓包能看到请求出去、回包永远不来"，非常像玄学问题，查半天网络策略也查不出来。

VLAN 打标只能在一处做。要么在虚拟交换机端口上做访问模式打标，虚机里看到的是无标记帧；要么在设备内部做 802.1Q 子接口。两头都打，结果就是双重标签，上游交换机看不懂，直接丢弃。规划时先定死在哪一侧做，写进文档，后面加网卡时照着来。

4. 让它真正干活：虚拟服务器、服务组、监视器的最小闭环

到这一步虚机已经能登录了，但还只是个空壳。真正开始转发流量需要三个对象串起来：虚拟服务器承接外部请求，服务组管理后端成员，监视器判断成员是否健康。三者缺一个，流量都不会按预期走。

4.1 单臂还是双臂：虚拟交换机上先想清楚流量路径

单臂的做法是进出都走同一块网卡，靠 VLAN 子接口区分内外。省网卡，但流量翻倍——同样一个请求，进来一份出去一份，都压在同一块虚拟网卡上，虚拟交换机同一端口的双向大流量处理效率不如物理交换机，容易在压测时先撞到虚拟交换机的瓶颈而不是设备本身。

双臂是入口一块、出口一块，路径清晰，压测时能明确知道瓶颈在哪一侧。代价是多占一块网卡和一个交换机端口。除非宿主机网卡资源确实紧张，我一般直接上双臂。

不管单臂双臂，后端服务器回包的处理都要提前想。默认情况下设备会做源地址转换，后端看到的源 IP 是设备的 SNAT 地址，回程只要路由能回到设备就行。如果业务需要后端看到真实客户端 IP，就得关掉转换并把设备设为网关，这时候网络拓扑要求更严格，不是所有环境都能做。

# 启用 USNIP，让设备对后端做源地址转换，后端无需把设备设为网关 enable ns mode USNIP # 若需要指定转换后的源地址，用 netprofile 固定，避免走后端回程路由异常 add netprofile np_snat -srcIP 10.10.20.10

USNIP是使用子网 IP 做转换的开关，属于全局模式，开了之后所有走虚拟服务器的流量默认走转换。netprofile用在多出口场景，把转换源地址固定成某个可达地址，避免后端回程路由选错。这两个东西看着不起眼，但一旦后端是多网卡多网段的环境，不配的话回包永远回不来。

4.2 用 NITRO API 一次下发整套配置

图形界面配一遍能跑，但要复制到第二套环境就得重来。NITRO 是设备提供的 REST 接口，把配置写成脚本，重建环境时一条命令跑完，比手工点快得多，也不容易漏。

import requests, urllib3 urllib3.disable_warnings() # 实验环境自签证书，生产建议导入 CA BASE = "https://192.168.10.10/nitro/v1/config" sess = requests.Session() sess.verify = False # 1) 登录换 token，后续请求靠 Cookie 认证 r = sess.post(f"{BASE}/login", json={"login": {"username": "nsroot", "password": "CHANGE_ME"}}, timeout=10) sid = r.json()["sessionid"] sess.headers.update({"Cookie": "NITRO_AUTH_TOKEN=" + sid, "Content-Type": "application/json"}) def push(kind, body): """统一的下发入口：200/201 成功，409 视为已存在跳过，其余打印原文""" resp = sess.post(f"{BASE}/{kind}", json=body, timeout=15) if resp.status_code in (200, 201): print("OK ", kind) elif resp.status_code == 409: print("SKIP", kind, "already exists") else: print("FAIL", kind, resp.status_code, resp.text[:200]) # 2) 服务组，并绑定健康检查监视器 push("servicegroup", {"servicegroup": { "servicegroupname": "sg_web", "servicetype": "HTTP", "lbmonitor": "mon_http"}}) push("servicegroup_servicegroupmember_binding", {"servicegroup_servicegroupmember_binding": { "servicegroupname": "sg_web", "ip": "10.10.20.11", "port": 8080}}) # 3) 虚拟服务器，最少连接算法，绑服务组 push("lbvserver", {"lbvserver": { "name": "vs_web", "servicetype": "HTTP", "ipv46": "10.10.10.100", "port": 80, "lbmethod": "LEASTCONNECTION"}}) push("lbvserver_servicegroup_binding", {"lbvserver_servicegroup_binding": { "name": "vs_web", "servicegroupname": "sg_web"}})

URL 命名规则要记牢：/nitro/v1/config/<资源名>，POST 新增、PUT 修改、DELETE 删除。带下划线的资源是绑定关系，比如servicegroup_servicegroupmember_binding，命名格式是"父资源_子资源_binding"，写错一个字母就是 404。

409 要单独处理。批量脚本跑第二遍时，已经存在的对象会返回 409，如果当成失败处理，整个任务的退出码就是非零，CI 里直接红灯。把 409 归到 SKIP，脚本才能幂等。

lbmethod的取值里，ROUNDROBIN适合后端性能一致且请求耗时接近的场景，LEASTCONNECTION适合请求耗时差异大的场景，RESPONSETIME会按响应时间动态加权，但需要监视器提供足够准确的耗时数据。默认我给LEASTCONNECTION，绝大多数业务都能吃到好处。

4.3 监视器三个参数怎么调才不误判

监视器决定后端什么时候被摘掉。参数调得太激进，后端一次 GC 停顿就被摘，流量打到剩余节点造成雪崩；调得太保守，后端已经挂了还在接流量，用户侧直接报错。

# HTTP 监视器：每 5 秒探测一次，单次 3 秒超时，连续 3 次失败判死 add lb monitor mon_http HTTP -interval 5 -resptimeout 3 -retries 3 -downTime 30 bind servicegroup sg_web -monitorName mon_http # 后端健康检查接口只认 GET 时，用 ECV 显式指定方法与匹配串 add lb monitor mon_ecv HTTP-ECV -send "GET /healthz\r\n" -recv "OK" -interval 10 -retries 2

判定时间 = interval × retries + resptimeout，上面这组是 5×3+3，最坏 18 秒摘除。downTime是延迟标记时间，成员恢复后要等 30 秒才重新纳入，防止抖动型故障导致流量反复切换。

HTTP类型的监视器默认发的是HEAD /，后端如果只对GET返回 200，就会被误判成下线。这个现象很迷惑：手工 curl 是通的，设备上却显示 DOWN。改用HTTP-ECV显式指定方法就能解决。-send里的\r\n不能省，少了它请求行不完整，后端直接返回 400。

探测频率也别一味调快。几十个后端成员、1 秒探测一次，光是健康检查的流量就够后端喝一壶。一般 5 到 10 秒足够，业务对故障切换极敏感的再压到 3 秒，但要同步评估后端承接能力。

4.4 SSL 卸载：证书链、密钥与绑定顺序

卸载的意义是把加解密集中到设备上，后端只处理明文，省掉每台服务器各自维护证书的麻烦。配的时候顺序有讲究。

# 1) 证书与私钥先传到 /nsconfig/ssl 目录 shell "ls -l /nsconfig/ssl" # 2) 建立证书对象，私钥不能带口令 add ssl certKey cert_wild -cert server.crt -key server.key # 3) 建前端 SSL 配置，按需启停协议版本 add ssl profile ssl_front -sslProfileType FrontEnd -tls1 DISABLED -tls11 DISABLED -tls12 ENABLED -tls13 ENABLED # 4) 挂到虚拟服务器上，再绑定证书 set ssl vserver vs_web -sslProfile ssl_front bind ssl vserver vs_web -certkeyName cert_wild

顺序反了会报"没有可用证书"之类的错误，因为set ssl vserver在部分构建上会校验当前是否有已绑定的证书。稳妥做法就是先建对象、再设配置、最后绑定。

证书链是最常见的翻车点。server.crt里必须包含服务器证书和全部中间证书，顺序是从服务器证书开始逐级往上，根证书不要放——根证书在客户端本地就有，放进去反而会增大握手包体积。链不全的表现是浏览器能打开、但部分安卓客户端和命令行工具报证书验证失败，排查时容易误判成设备问题。

私钥不能带口令。带口令的私钥导入时会提示输入，但有些自动化流程没法交互，最后得到的是一个空对象，绑定成功但握手失败。上传前先转成无口令格式，省事。

5. 避坑与排查：Hyper-V 上跑 NSVPX 的 5 个翻车现场

这些坑的共同点是：配置看着全对，现象却完全不讲道理。下面每条都按"现象、原因、解决"写，方便对着排查。

5.1 控制台停在一行启动提示不动，反复重启

现象：虚机加电后控制台只显示一两行引导信息，然后长时间无输出，或者进入重启循环。

原因：虚拟机代次选成了第 2 代。第 2 代只支持 UEFI 引导和 VHDX，而镜像盘是 BIOS 引导结构的 VHD，两者对不上，引导程序找不到入口就停在那里。

解决：删掉重建，-Generation 1，磁盘挂 IDE 控制器 0 号位置。已经转成 VHDX 的也别指望救回来，格式转换不改引导结构，重建最快。

5.2 控制台里地址正确，ping 不通网关

现象：控制台里show interface看到地址和掩码都对，ping网关全是超时，ARP 表里网关那条记录一直是未完成状态。

原因：虚拟交换机的源 MAC 校验把帧丢了。设备转发时要改写源 MAC，虚拟交换机发现不是分配的那个 MAC，直接丢弃。另一种可能是 VLAN 在虚拟交换机端口和设备内部各打了一次，双重标记被上游丢弃。

解决：Set-VMNetworkAdapter -MacAddressSpoofing On打开；VLAN 只在一侧配置，要么虚拟交换机访问模式，要么设备内部子接口，二选一。改完重启网卡或者重启虚机生效。

5.3 克隆出来的第二台，管理地址互相打架

现象：两台设备同时在线，管理地址的 ARP 记录在两个 MAC 之间来回跳，登录时有时连到这台有时连到那台。

原因：克隆虚机时把静态 MAC 一起复制了。两台虚机在同一个虚拟交换机上用了同一个 MAC，交换机学习到的端口不断切换。

解决：克隆后立刻改 MAC，Set-VMNetworkAdapter -VMName 新虚机名 -DynamicMacAddress让它自动分配，或者手工指定一个不冲突的静态值。台账里给每台虚机记一个 MAC，编号用完再回收。

5.4 两台设备时间越跑越偏，同步状态时好时坏

现象：双机部署下，两台设备的日志时间差几十秒，同步状态间歇性断开又恢复，日志里能看到心跳超时的记录。

原因：Hyper-V 集成服务里的时间同步开着，会和设备自身的 NTP 客户端抢时钟源。两个源给的偏差不一样，时钟就被来回拉扯。

解决：关掉虚机的时间同步集成服务，只保留设备内部的 NTP 配置。两台设备的 NTP 都指向同一个上游源，偏差控制在秒级以内。

5.5 改完配置直接重启，配置回到出厂状态

现象：命令行里改了一堆，show ns runningConfig能看到，重启之后全没了，恢复成刚导入时的样子。

原因：改的是运行配置，没写进持久化存储。也有情况是脚本执行到一半中断，前面的命令生效了，最后的保存语句没跑到。

解决：变更脚本末尾统一加save ns config，并且把这一条做成幂等操作——重复执行不影响结果。变更单里单独列一行"已保存"，比事后回忆可靠得多。

6. 上线前的验证清单和一个压测小技巧

配置跑通不等于可以上线。上线前那半天，我一般按一张固定清单过一遍，每次都过，不因为"这次改动很小"就跳。跳过的次数多了，总有一次会还回来。

压测阶段有个小技巧：别只看压测工具那头的成功率，同时开着设备侧的计数看。两个数对不上，问题就在中间环节。

# 压测期间每 2 秒采样一次虚拟服务器命中速率与丢包计数 # 字段位置随构建号略有差异，先完整输出一次 stat 确认结构再调 awk while true; do printf '%s ' "$(date +%T)" stat lb vserver vs <p> <a href="https://download.csdn.net/download/weixin_43304263/88112869" style="color:#ec7500;font-size:14px;"> 本文还有配套的精品资源，点击获取 </a> <img alt="menu-r.4af5f7ec.gif" src="https://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif" style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;"> </p>