Competition Runtime Routing

$ctf-sandbox-orchestrator

$ctf-sandbox-orchestrator

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