mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-08-06 07:12:12 +03:00
* 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).
251 lines
12 KiB
Markdown
251 lines
12 KiB
Markdown
---
|
|
title: "Egress IP Family Policy (IPv4/IPv6)"
|
|
version: 3.8.40
|
|
lastUpdated: 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](#what-it-is)
|
|
- [Why It Exists](#why-it-exists)
|
|
- [The Three Values](#the-three-values)
|
|
- [How to Configure It](#how-to-configure-it)
|
|
- [How `auto` Resolves](#how-auto-resolves)
|
|
- [How `ipv4` / `ipv6` Are Enforced](#how-ipv4--ipv6-are-enforced)
|
|
- [SOCKS5 Compatibility](#socks5-compatibility)
|
|
- [Fail-Closed Behavior](#fail-closed-behavior)
|
|
- [Data Model](#data-model)
|
|
- [Related Documentation](#related-documentation)
|
|
|
|
---
|
|
|
|
## What It Is
|
|
|
|
Every proxy in the registry has a `family` field with three possible values, validated by a Zod enum:
|
|
|
|
```ts
|
|
// 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`:
|
|
|
|
```ts
|
|
// 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](https://github.com/diegosouzapw/OmniRoute/pull/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`](../../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`:
|
|
|
|
```bash
|
|
# 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](#data-model)).
|
|
|
|
For the rest of the proxy CRUD/assignment API, see [PROXY_GUIDE.md](../ops/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:
|
|
|
|
```ts
|
|
// 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:
|
|
|
|
```ts
|
|
// 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):
|
|
|
|
```ts
|
|
// 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)).
|
|
|
|
---
|
|
|
|
## 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:
|
|
|
|
```ts
|
|
// 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 | 6` → `createSocksDispatcherWithFamily`, 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](../ops/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`:
|
|
|
|
```ts
|
|
// 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:
|
|
|
|
```sql
|
|
-- 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
|
|
|
|
> 📖 **Related documentation:**
|
|
>
|
|
> - [Proxy Guide](../ops/PROXY_GUIDE.md) — full proxy system: registry CRUD, 4-level resolution, rotation, health checking, API reference
|
|
> - [Stealth Guide](./STEALTH_GUIDE.md) — TLS fingerprint and CLI fingerprint layers that ride on top of the proxy
|
|
> - [Route Guard Tiers](./ROUTE_GUARD_TIERS.md) — loopback enforcement for local-only routes
|