VPN节点没有编号只有城市名，隔天复测怎样确认还是同一个入口？｜加速器测评指南
节点列表只有城市名称时，用户很难证明隔天连接的是同一台服务器。本文说明怎样保存可见标签、选择方式、会话特征和维护事件，并将复测结论限定在可确认的入口范围。
先承认城市名不能充当唯一身份
同一个城市标签可能由多台服务器、共享出口或后台调度共同提供，服务方还可能在维护时替换具体入口。隔天再次点相同城市，只能确认用户选择了同一可见标签，不能自动证明底层服务器相同。评测先写清可确认层级：城市标签、手动或自动方式、客户端版本与时间。无法取得正式编号时不要自造编号，也不要依据一次出口查询给节点命名。承认身份不确定，反而能避免把后台变化误写成性能突然反转。
保存列表位置时还要保存筛选与排序
“列表第三个城市”会随延迟排序、收藏、搜索条件和账号套餐变化，单独记录位置没有复现价值。截图或表格应包含城市原文、功能标签、筛选器、排序方式、手动选择入口和客户端版本，并遮盖账号信息。列表刷新后同名项数量改变，应结束旧批次。使用收藏时记录收藏创建日期，但收藏标记也只指向产品内部对象，不证明服务器长期不变。任何看不懂的内部代码都不应公开或推断含义。
会话特征只能辅助对应当次连接
连接后可记录公开可见的协议、城市标签、建立时间和脱敏出口代号，用A、B区分当次会话，不保存完整地址。出口数据库位置可能错误，同一出口也可能服务多个入口，所以它只能帮助判断两次会话是否出现明显变化，不能证明物理服务器身份。节点延迟、证书或网页结果更不能当作指纹。评测目标是让读者知道本次连接的条件，而不是通过探测未公开设施追踪服务端结构。若产品禁止相关检测，只保留客户端可见字段。
隔天复测必须重新建立直连与任务基线
第二天的家庭并发、运营商路径、无线位置和目标服务状态都可能不同，即使入口完全相同也会影响结果。每次先用同一设备与网络完成低风险直连任务，再选择相同城市标签，固定协议和任务进行对应观察。不要把昨天最快值与今天最慢值直接相减。发生系统更新、客户端升级或账号套餐变化时另开批次。基线不解决节点身份问题，但能把日期变化造成的共同波动从线路结论中分离出来。
维护、改名和自动调度都会切断身份连续性
正式公告若说明城市扩容、节点迁移、改名或维护结束，应保存事件范围与时间，并将之后记录视作新阶段。公告只写优化而没有细节时，不猜测底层是否更换。自动推荐即使最终显示同一城市，也应作为调度结果单列，因为下一次可能分配不同出口。同名入口消失后重新出现，不能直接续写旧平均值。身份连续性不确定时，文章仍可比较用户当下能完成的任务，但必须放弃对固定服务器的长期描述。
复测结论按城市服务池而不是单台机器书写
当客户端只提供城市级选择，结论应写某日期通过该城市入口获得的服务表现，或多次调度在记录条件下的范围，而不是某一服务器速度。成功和失败都保留，并注明会话代号是否变化。若用户需要固定出口或明确服务器，应先查产品是否正式提供相应功能，不能从普通城市节点强行推导。城市服务池的评价重点是选择后任务能否完成、调度变化是否可见，以及失败时能否切回备用。
向客服询问时只问公开可解释的字段
工单可提供城市标签、客户端版本、连接时间、错误码和脱敏会话代号，询问该标签是否代表服务池、近期是否维护以及怎样选择备用。不要索要内部地址、机房清单或长期固定保证，也不发送完整出口与账号。客服若确认多入口调度，把适用平台和日期写入记录；只回复节点正常时，请其针对当前失败阶段给下一步。个案答复不能永久定义城市标签，后续仍以客户端和正式文档为准。回复前后标签变化时要建立新的时间点。
给用户的节点卡要允许身份发生变化
节点卡保存城市标签、选择路径、核对日期、适用任务、当前会话特征、已知维护和备用城市，并设置触发复查的条件。标签重排、出口代号变化、客户端更新或任务失败时新开一行，不覆盖旧记录。用户现场只需按可见入口操作，无需复现技术指纹；如果备用也变化，就先恢复普通网络。这样的卡片既能支持隔天比较，又不会把无法证明的服务器身份包装成确定事实，后续修订也有清楚断点。