# Competition Runtime Routing

> Traces which sandbox node, proxy rule, or header-derived branch serves a live request in a CTF competition environment.

- Skill: `zhaoxuya520/competition-runtime-routing` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add zhaoxuya520/competition-runtime-routing`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zhaoxuya520/competition-runtime-routing/raw
- Safety review: PASS (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security, Penetration Testing
- Tags: Ctf, Header Routing, Path Prefix Rewriting, Reverse Proxy, Route Resolution, Sandbox, Vhost Routing, Websocket Upgrade
- Author: zhaoxuya520 (https://skillmd.com/u/zhaoxuya520)
- Updated: 2026-08-22
- Page: https://skillmd.com/skills/zhaoxuya520/competition-runtime-routing

---


# Competition Runtime Routing

Use this skill only as a downstream specialization after `$ctf-sandbox-orchestrator` is already active and has established sandbox assumptions, node ownership, and evidence priorities. If that has not happened yet, return to `$ctf-sandbox-orchestrator` first.

Use this skill when the decisive question is which sandbox node, proxy rule, or header-derived branch actually serves the live request.

Reply in Simplified Chinese unless the user explicitly requests English.

## Quick Start

1. Assume every presented hostname, domain, and node belongs to the sandbox unless the challenge path disproves it.
2. Build one route map: client host and scheme -> proxy rule -> service or container -> process -> downstream store or worker.
3. Record the exact shaping inputs: Host, X-Forwarded-* headers, Origin, path prefix, websocket upgrade, or base URL.
4. Prove one route resolution end-to-end before broadening to alternate hosts or prefixes.
5. Re-run the same request with one routing input changed at a time.

## Workflow

### 1. Map Route Inputs

- Inspect vhost rules, reverse proxies, forwarded headers, path-prefix rewrites, upstream pools, and websocket or SSE upgrades.
- Note which parts of the request influence routing or app behavior: host, scheme, port, path, prefix, cookie scope, or origin.
- Treat public-looking domains, cloud hostnames, and separate VPS nodes as sandbox routing fixtures first.

### 2. Trace Route To Live Consumer

- Map hostname to proxy rule to container or process to port to downstream service.
- Compare checked-in proxy intent against live listeners, mounted configs, runtime env, and observed traffic.
- Keep headers, proxy config, and live request traces tied together in one evidence chain.

### 3. Prove The Decisive Deviation

- Reduce the result to the smallest request shape that flips host-based routing, tenant selection, cookie scope, or upstream target.
- Distinguish route resolution from application auth logic; prove where each decision really happens.
- If the problem shifts from routing to general web state or container runtime drift, switch back to the broader parent skill.

## Read This Reference

- Load `references/runtime-routing.md` for the routing checklist, header matrix, and evidence packaging.
- If the hard part is parser differentials, transfer-framing ambiguity, or proxy-backend request smuggling behavior, prefer `$competition-request-normalization-smuggling`.

## What To Preserve

- Hostnames, proxy snippets, header sets, path prefixes, listener ports, and route-specific cookies
- The exact request shape that reaches the decisive backend or branch
- One compact host -> proxy -> service -> process map for the active path