要记录多次请求使用了哪些不同出口，先承认：代理组通用字段提供的是候选集合、默认选择、健康检查与 api 展示，并没有给出一份每次请求出口的专用账本格式。适用条件是出口由某策略组决定，且你能定位该组 name。记录工作应分成三层：配置快照、可用性变化、展示接口。缺一层就会把筛选或探活造成的集合变化，误记成同一集合在轮流出站。
先记录候选集合快照，才能解释出口为何不同
每次准备观察前，写下该组必须的 type 以及引入通道。proxies 列表本身就是一份有序名单，可原样抄录。use 引入代理集合，成员不在 proxies 里。include-all、include-all-proxies、include-all-providers 会按名称排序生成名单；include-all 不含策略组，include-all-providers 会使引入代理集合失效。判断依据：若两次请求出口不同，先比较这两份快照是否已经不同。集合内容刷新或 filter 变更都会改名单，这时应记集合变了，而不是记同一集合在切换出口。
filter 与 exclude-filter 用关键词或正则限制引入代理集合以及引入所有出站代理的结果，多个正则可用反引号区分。exclude-type 用竖线按类型排除引入的出站代理，无视大小写。这三项要记进快照，否则名单对不上出口。default-selected 为空或名字不存在时选第一个节点，因此快照里必须标明排序后的第一项。组名有特殊符号时要用引号包裹，避免记到错误的组。场景步骤：先导出最终节点名，再标出第一项与默认项，最后才去对比两次请求看到的出口字符串。
再记录健康检查是否改写了当时可用的人
即使配置文本没变，可用集合也可能变。应记录：url 测试地址、interval 是否非 0、lazy 是否为默认 true、timeout、max-failed-times（默认 5）、expected-status（默认星号）。关键限制必须写在记录里：组级健康检查只覆盖 proxies，不覆盖 use 引入的节点。因此，对 proxies 成员，可用或不可用变化可以解释后续请求改走他人；对 use 成员，不能用该组 url 的探测记录去解释。
expected-status 一旦配置，只有状态码一致才可用，可用斜线与短横写多码和范围。把探测失败的节点从本次可能出口划掉，剩余节点才是多次请求真正可能出现的不同出口。lazy 为 true 时，组未被选中则不测试，刚开始使用该组时可用状态可能尚未更新，多次请求的出口记录会前一段与后一段不一致，这应标注为懒惰测试导致的集合未就绪。
展示字段不是流量记录，失败时下一步
hidden 在 api 返回 hidden 状态以隐藏策略组展示，icon 在 api 返回图标字符串，都需要使用 api 的前端适配。它们可以辅助你在前端找到该组，但不能当作请求级出口日志。disable-udp 只说明 UDP 是否禁用。empty-fallback 只在组为空时生效，且只能是 proxy 名称。组级 interface-name、routing-mark 已弃用，不能用来记录出站接口或路由标记，应到节点配置里查，优先级为代理节点大于代理策略大于全局。
失败时下一步：若完全没有不同出口可记，先确认观察的是同一 name，并导出 proxies、use、include 与 filter 快照。若有不同出口但无法对应到请求，检查这些名字是否仍在快照中、是否仅因 expected-status 或超时被判不可用、是否其实来自 use 而你在看组级探测。若记录显示组为空，核对 empty-fallback。不要编造请求日志字段；通用文档能支持的记录就是这些配置与探活条件。需要前端看见组时，再考虑 hidden 与 icon 是否让组从 api 展示中消失。