Files
OmniRoute/docs/security/EGRESS_POLICY.md
Diego Rodrigues de Sa e Souza 5ac4637816 docs: reorganize docs/ + accuracy audit + drop Node 20 (rebased onto current release tip) (#5262)
* docs: move superpowers/research artifacts to isolated _tasks repo + docs tree cleanup

- Move docs/superpowers/{plans,specs} and docs/research/* into the gitignored,
  separately-versioned _tasks/ repo; untrack the two tracked research design docs.
- Add CLAUDE.md "Planning & Research Artifacts" section overriding the superpowers
  default save paths (docs/... -> _tasks/...); align REPOSITORY_MAP and
  DOCUMENTATION_OVERHAUL_PLAN with the new convention.
- Drop 4 now-obsolete /api/discovery/* entries from check-docs-symbols allowlist
  (stale-enforcement) and refresh code/spec path comments to _tasks/...
- Sweeps in concurrent docs-tree restructuring (root-level provider/guide docs,
  compression spec cleanup, .mcp.json.example removal).

* docs: reorganize docs/ tree + fix stale facts across ~26 docs

Phase A — reorganization:
- Move 7 orphan root docs into subfolders (providers/ created; TIERS+USAGE_QUOTA→guides/;
  plugins+PLUGIN_SDK→frameworks/); delete 8 obsolete/redundant docs (SUBMIT_PR superseded
  by CONTRIBUTING; DOCUMENTATION_OVERHAUL_PLAN; INCIDENT_RESPONSE/PERF_BUDGETS/THREAT_MODEL;
  3 ops snapshots). Rebuild README index (was missing ~40 files) + per-folder meta.json nav.
- Clean 14 dangling doc-path references in bin/ ops scripts, scripts/, workflow, tests;
  fix the dockerignore-docs-coverage required-docs path (PROVIDERS→providers/CLAUDE_WEB).

Phase B — content accuracy (verified against code, not the audit summary):
- Functional: ENVIRONMENT flag defaults (INPUT_SANITIZER/MCP_ENFORCE_SCOPES=true,
  COMPRESS_DESCRIPTIONS=false, dynamic heap); MCP-SERVER notion tool names (omniroute_*→
  notion_*) + counts 87→94; coverage gate 75/70→60/60/60/60 (RELEASE_CHECKLIST, COVERAGE_PLAN,
  ERROR_SANITIZATION, CONTRIBUTING); pre-push hook description; regenerate PROVIDER_REFERENCE (237).
- Count drift: providers 237, executors 70, migrations 106, db modules 94, oauth 19,
  strategies 17, MCP 94, flags 38, TS 6.0, open-sse ~900/services 294 across architecture/
  frameworks/ops docs; AUTO-COMBO 9→12 factors w/ correct DEFAULT_WEIGHTS; REASONING +2
  patterns; STEALTH UA defaults; AGENT_PROTOCOLS +cursor-cloud/list-capabilities;
  LANGUAGE_PACKS +id pack.
- Kept Node 20 (runtime guard accepts 20.20.2+; only engines is stricter) and MCP scopes=13
  (mcpScopes.ts) — both were correct in the docs; corrected only the attribution.

* docs: finish content refresh — compression engines, CLI_TOKEN merge, metadata sweep

- Compression: document the additional built-in engines (CCR, headroom, ionizer,
  session-dedup) in COMPRESSION_ENGINES; clarify LLMLingua-2 is the ultra-mode SLM
  backend + cross-ref the extra engines in EXTENDING_COMPRESSION; add the id
  (Indonesian) language pack to LANGUAGE_PACKS.
- AUTO-COMBO: replace the orphan 'How tiers fit' weight table (stale weights) with a
  pointer to the canonical 12-factor DEFAULT_WEIGHTS table.
- Security: merge CLI_TOKEN_AUTH.md (legacy 32-char SHA-256 format) into CLI_TOKEN.md
  as a 'Legacy format — still accepted' section (server accepts both HMAC + legacy),
  delete CLI_TOKEN_AUTH.md, drop it from the index + security nav.
- Metadata: bump stale frontmatter (version/lastUpdated) to 3.8.40/2026-06-28 across the
  doc set audited this pass, and normalize the in-body 'Last updated' header lines to match.

* fix(runtime): drop Node 20 from supported range + align all docs/diagrams/counts

- Node minimum is now 22 (aligned with package.json engines). SUPPORTED_NODE_RANGE in
  src/shared/utils/nodeRuntimeSupport.ts (and the bin/ mirror) drops the 20.x line →
  '>=22.22.2 <23 || >=24.0.0 <27'; getNodeRuntimeSupport now rejects Node 20 as
  unsupported-major. Test updated (TDD): node-runtime-support.test.ts asserts Node 20
  rejected. Docs aligned (TROUBLESHOOTING ×2, TERMUX, RELEASE_CHECKLIST, CODEBASE,
  CLI-TOOLS, README, llm.txt + 42 i18n llm.txt mirrors, skills/cli-serve).
- Diagrams regenerated: mcp-tools-87 -> mcp-tools-94 (34 base + pool 6 = 94) and
  auto-combo-9factor -> auto-combo-12factor (correct DEFAULT_WEIGHTS); SVGs re-rendered
  via mermaid-cli; doc refs + diagrams/README updated; fixed a pre-existing broken
  resilience-3layers image path.
- CLAUDE.md + AGENTS.md aligned to real counts (237 providers, 94 MCP tools / 34 base,
  106 migrations, 94 db modules, 12-factor auto-combo, 17 strategies); README provider
  count 231 -> 237; executor count corrected to 68 (provider executors, excl base/index)
  and OAuth to 18 across architecture docs. check:docs-all now passes (0 strict drift,
  0 broken links); removed dead .mcp.json.example doc link.

* fix(services): update installer Node hint to >=22.22.2 (aligned with dropped Node 20)

* docs: realign counts to current release tip after rebase

The release tip advanced while this work was in flight (Gemini CLI provider/executor
removed by #5246, plus other PRs). Re-counted against the current code and updated:
providers 237->236, executors 68->67, OAuth modules 18->17, open-sse services 294->298;
regenerated PROVIDER_REFERENCE.md (236). check:docs-all passes (0 strict drift).

* docs(changelog) + i18n: record Node 20 drop + fix nodeIncompatibleHint

- CHANGELOG: add [3.8.40] entries for the Node 20.x removal (runtime) and the docs
  reorganization/accuracy audit.
- i18n: nodeIncompatibleHint across all 42 locales no longer lists Node 20.x as
  supported (ASCII + CJK full-width variants), aligned with the dropped Node 20.

* fix(docs): repair CI breakages from the doc moves

- test: cli-plugin-system asserted docs/dev/plugins.md exists; the file moved to
  docs/frameworks/PLUGINS.md — point the test at the new path (Unit fast-path 2/2 fix).
- frontmatter: PLUGINS.md and PLUGIN_SDK.md moved into the fumadocs-indexed
  docs/frameworks/ which requires a 'title' frontmatter; the missing frontmatter
  failed the Next.js MDX build (dast-smoke 'invalid frontmatter'). Added frontmatter
  to both, plus the providers/ docs (consistency; that folder is not indexed).
2026-06-28 22:07:18 -03:00

12 KiB

title, version, lastUpdated
title version lastUpdated
Egress IP Family Policy (IPv4/IPv6) 3.8.40 2026-06-28

Egress IP Family Policy (IPv4/IPv6)

Pin outbound traffic to a single IP family — auto, ipv4, or ipv6 — per proxy, so an IPv6-only egress never silently leaks back to IPv4.

Source of truth: open-sse/utils/proxyFamily.ts, open-sse/utils/proxyDispatcher.ts, open-sse/utils/proxyFetch.ts, open-sse/utils/socksConnectorWithFamily.ts, open-sse/utils/proxyFamilyResolve.ts, src/shared/validation/schemas.ts, src/lib/db/proxies.ts, src/lib/db/upstreamProxy.ts, src/lib/db/migrations/099_proxy_family.sql

OmniRoute lets each proxy carry an address-family egress directive. By default the OS picks IPv4 or IPv6 (dual-stack, "Happy Eyeballs"). When you set the directive to ipv4 or ipv6, OmniRoute pins every connection through that proxy to the chosen family and fails closed rather than falling back to the other family.

This page documents what the directive is, why it exists, where you configure it, and how the runtime resolves it.


Table of Contents


What It Is

Every proxy in the registry has a family field with three possible values, validated by a Zod enum:

// src/shared/validation/schemas.ts
family: z.enum(["auto", "ipv4", "ipv6"]).optional().default("auto"),

The field defaults to "auto", which preserves the prior dual-stack behavior. Setting it to ipv4 or ipv6 pins the connect family for that proxy.

The directive is normalized everywhere through a single helper so any unknown value collapses to auto:

// open-sse/utils/proxyFamily.ts
export type ProxyFamily = "auto" | "ipv4" | "ipv6";

export function parseProxyFamily(value: unknown): ProxyFamily {
  return value === "ipv4" || value === "ipv6" ? value : "auto";
}

Why It Exists

Introduced in PR #3777. The motivating problems:

Problem What the directive fixes
IPv6-only egress leaking to IPv4 When a proxy host has both A and AAAA records (or the OS prefers IPv4), Happy Eyeballs can dial out over IPv4 even when you intend an IPv6-only path. Pinning ipv6 removes that leak.
Shared-egress anomaly revocation Rotating providers (codex/openai) revoke tokens when many accounts egress through the same IP at high volume. Controlling the egress family is part of keeping accounts on distinct, predictable egress paths (see src/lib/proxyEgress.ts for the egress-IP diagnostics that pair with this).
Deterministic egress for compliance/testing When you must guarantee traffic leaves over a specific family, auto is not enough.

The directive is intentionally per-proxy, not global — different proxies in your pool can have different policies.


The Three Values

Value UI label Behavior
auto Auto (dual-stack) OS picks the family. For an IP-literal proxy host, the family is intrinsic to the literal; for a hostname, both families are eligible. This is the default.
ipv4 IPv4 only Pins the connection to IPv4. Fails closed if the proxy host has no IPv4 (A) record.
ipv6 IPv6 only Pins the connection to IPv6. Fails closed if the proxy host has no IPv6 (AAAA) record.

UI strings live in src/i18n/messages/en.json (labelFamily, familyAuto, familyIpv4, familyIpv6, familyHint).


How to Configure It

Dashboard

The selector is in the proxy form of the Proxy Pool tab:

  1. Open Dashboard → Settings → Proxy → Proxy Pool
  2. Add or edit a proxy
  3. Set the IP family dropdown to Auto (dual-stack), IPv4 only, or IPv6 only
  4. Save

The control is rendered by ProxyRegistryManager.tsx (mounted in proxy/ProxyPoolTab.tsx).

API

The family field is part of the proxy registry create/update payloads, validated by createProxyRegistrySchema / updateProxyRegistrySchema (src/shared/validation/schemas.ts) and handled by POST / PATCH /api/v1/management/proxies:

# Create an IPv6-only proxy
curl -X POST http://localhost:20128/api/v1/management/proxies \
  -H "Content-Type: application/json" \
  -d '{
    "name": "IPv6 egress",
    "type": "socks5",
    "host": "proxy.example.com",
    "port": 1080,
    "family": "ipv6"
  }'

# Change an existing proxy to IPv4-only
curl -X PATCH http://localhost:20128/api/v1/management/proxies \
  -H "Content-Type: application/json" \
  -d '{ "id": "proxy-uuid-here", "family": "ipv4" }'

The same field is also accepted by the inline proxy config object used for upstream-proxy entries (upstream_proxy_config.family, see Data Model).

For the rest of the proxy CRUD/assignment API, see PROXY_GUIDE.md.


How auto Resolves

When family is auto, OmniRoute does not append any directive — the proxy URL is used as-is and the connect family is determined intrinsically.

At URL-build time (proxyConfigToUrl / normalizeProxyUrl in open-sse/utils/proxyDispatcher.ts), an auto proxy yields a plain URL with no marker:

// open-sse/utils/proxyDispatcher.ts
const fam = parseProxyFamily(config.family);
const normalized = normalizeProxyUrl(proxyUrlStr, "context proxy", { allowSocks5 });
return fam === "auto" ? normalized : `${normalized}?family=${fam}`;

At dispatch time (resolveDispatcherFamily), auto resolves to the intrinsic family of an IP-literal host, or null (let the OS decide) for a hostname:

// open-sse/utils/proxyDispatcher.ts
function resolveDispatcherFamily(parsed: URL): 4 | 6 | null {
  const directive = parseProxyFamily(parsed.searchParams.get("family") ?? undefined);
  const literal = detectIpLiteralFamily(parsed.hostname);
  if (directive === "auto") return literal; // null for a hostname → OS picks
  // ...
}

So:

  • auto + IP-literal host (192.0.2.1 / [2001:db8::1]) → family of that literal.
  • auto + hostname → null → standard dual-stack OS resolution.

How ipv4 / ipv6 Are Enforced

A non-auto directive travels as a single synthetic query marker — ?family=ipv4 or ?family=ipv6 — appended once to the normalized proxy URL. normalizeProxyUrl is careful to strip and re-append this marker exactly once so it never corrupts port parsing.

When the dispatcher is built, the marker is read and converted to a concrete connect family. If the host is an IP literal of the opposite family, OmniRoute throws (contradiction is fail-closed):

// open-sse/utils/proxyDispatcher.ts
const want = directive === "ipv6" ? 6 : 4;
if (literal !== null && literal !== want) {
  throw new Error(
    `[ProxyDispatcher] Proxy family directive ${directive} contradicts ${literal === 6 ? "IPv6" : "IPv4"} literal host`
  );
}

The concrete family is then pinned on the connector:

  • HTTP/HTTPS proxies (ProxyAgent): proxyTls: { family, autoSelectFamily: false } — disables Happy Eyeballs so the chosen family is the only one dialed.
  • SOCKS5 proxies: a custom connector threads socket_options: { family, autoSelectFamily: false } into the SOCKS client (see SOCKS5 Compatibility).

SOCKS5 Compatibility

The family pin works with SOCKS5 proxies, but stock fetch-socks does not expose the socket options needed to pin the family of the proxy hop. OmniRoute ships its own connector for that:

// open-sse/utils/socksConnectorWithFamily.ts
export function buildSocksFamilySocketOptions(family: 4 | 6 | null): Record<string, unknown> {
  if (family === 6) return { family: 6, autoSelectFamily: false };
  if (family === 4) return { family: 4, autoSelectFamily: false };
  return {};
}

createProxyDispatcher chooses the connector based on whether a family is pinned:

  • family === null (i.e. auto over a hostname) → stock socksDispatcher from fetch-socks.
  • family === 4 | 6createSocksDispatcherWithFamily, which threads socket_options into SocksClient.createConnection so Happy Eyeballs cannot pick IPv4 for an IPv6-only egress policy.

SOCKS5 support itself is on by default (opt-out via ENABLE_SOCKS5_PROXY=false); see PROXY_GUIDE.md → Environment Variables.


Fail-Closed Behavior

The whole point of the directive is to refuse rather than silently fall back to the wrong family. Two guards enforce this:

  1. Literal contradiction — a directive that contradicts an IP-literal host throws at dispatcher build time (resolveDispatcherFamily, shown above).

  2. Hostname pre-flight DNS check — for a hostname proxy with a pinned family, proxyFetch.ts verifies the hostname actually has a record in the required family before egressing, via assertHostnameSupportsFamily:

    // open-sse/utils/proxyFamilyResolve.ts
    const hasFamily = records.some((r) => r.family === family);
    if (!hasFamily) {
      throw new Error(
        `[ProxyFamily] Proxy host ${host} has no ${family === 6 ? "IPv6 (AAAA)" : "IPv4 (A)"} record; ` +
          `refusing ${family === 6 ? "IPv6" : "IPv4"}-only egress (fail-closed)`
      );
    }
    

    On failure, proxyFetch.ts tags the error with code = "PROXY_FAMILY_UNAVAILABLE" and statusCode = 503. A DNS resolution failure is likewise treated as fail-closed (refuse to egress).

IP-literal hosts are a no-op for the DNS pre-flight — their family is intrinsic and needs no lookup.


Data Model

The family column was added by migration 099_proxy_family.sql to two tables:

-- src/lib/db/migrations/099_proxy_family.sql
ALTER TABLE proxy_registry ADD COLUMN family TEXT NOT NULL DEFAULT 'auto';
ALTER TABLE upstream_proxy_config ADD COLUMN family TEXT NOT NULL DEFAULT 'auto';
  • proxy_registry.family — the per-proxy directive for registry entries (src/lib/db/proxies.ts). Resolution queries select family alongside the other proxy columns, and a missing/non-string value is coerced to "auto".
  • upstream_proxy_config.family — the directive for upstream-proxy entries (src/lib/db/upstreamProxy.ts), with the same "auto" default.

When a resolved proxy object carries a non-auto family, proxyConfigToUrl appends the ?family= marker so the pin survives all the way to the dispatcher.


📖 Related documentation:

  • Proxy Guide — full proxy system: registry CRUD, 4-level resolution, rotation, health checking, API reference
  • Stealth Guide — TLS fingerprint and CLI fingerprint layers that ride on top of the proxy
  • Route Guard Tiers — loopback enforcement for local-only routes