关于 competition-runtime-routing
面向 CTF 沙箱分析的专项技能，用于追踪实时请求经过的节点、代理规则和请求头分支。它以前置的 `$ctf-sandbox-orchestrator` 已建立沙箱假设为条件，强调端到端验证路由并保留证据链。
主要功能
- 01绘制主机到进程的路由图
- 02追踪请求头与路径前缀
- 03对照代理配置和实时流量
- 04验证最小路由变化请求
- 05整理路由证据链
适用场景
- 01判断实时请求由哪个节点处理
- 02定位 Host 或转发头导致的路由分支
- 03核实代理规则指向的后端服务
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/competition-runtime-routing确认已加载。
附带文件agents/openai.yamlreferences/runtime-routing.md
详细介绍
竞赛运行时路由
仅当 $ctf-sandbox-orchestrator 已处于活动状态，并已建立沙箱假设、节点归属和证据优先级之后，才将本技能作为下游专项使用。如果尚未满足这些条件，请先回到 $ctf-sandbox-orchestrator。
当决定性问题是哪个沙箱节点、代理规则或由请求头衍生的分支实际服务于实时请求时，请使用本技能。
除非用户明确要求英文，否则请用简体中文回复。
快速开始
- 除非挑战路径证明并非如此，否则假设呈现的每个主机名、域名和节点都属于沙箱。
- 构建一张路由图：客户端主机与 scheme -> 代理规则 -> 服务或容器 -> 进程 -> 下游存储或 worker。
- 记录精确的塑造输入：Host、X-Forwarded-* 请求头、Origin、路径前缀、websocket 升级或 base URL。
- 在扩展到备用主机或前缀之前，先端到端证明一次路由解析。
- 每次只更改一个路由输入，重新运行同一请求。
工作流
1. 梳理路由输入
- 检查 vhost 规则、反向代理、转发请求头、路径前缀重写、上游池，以及 websocket 或 SSE 升级。
- 记录请求的哪些部分会影响路由或应用行为：host、scheme、端口、路径、前缀、cookie 作用域或 origin。
- 首先将看似公开的域名、云主机名和独立 VPS 节点视为沙箱路由配置。
2. 追踪路由到实时消费者
- 将主机名映射到代理规则，再到容器或进程，再到端口，再到下游服务。
- 将已检入的代理意图与实时监听器、已挂载配置、运行时环境和观测到的流量进行对比。
- 将请求头、代理配置和实时请求追踪保留在同一条证据链中。
3. 证明决定性偏差
- 将结果缩减为能够翻转基于主机的路由、租户选择、cookie 作用域或上游目标的最小请求形态。
- 区分路由解析与应用认证逻辑；证明每个决策实际发生在哪里。
- 如果问题从路由转向通用 Web 状态或容器运行时漂移，请切回更广泛的上层技能。
阅读此参考
- 加载
references/runtime-routing.md以获取路由检查清单、请求头矩阵和证据打包方法。 - 如果难点是解析器差异、传输帧定界歧义或代理到后端的请求走私行为，请优先使用
$competition-request-normalization-smuggling。
需要保留的内容
- 主机名、代理片段、请求头集合、路径前缀、监听端口和路由专用 cookie
- 到达决定性后端或分支的精确请求形态
- 为活动路径绘制一张紧凑的 host -> proxy -> service -> process 映射图
评论
支持 Markdown