* feat(sub): parse generic Happ/INCY routing payloads for the JSON subscription Accepts the routing-rules format emitted for Happ and INCY (inline JSON, happ:// or incy:// deeplink, or a remote https:// URL resolved through the existing remote routing cache). The JSON subscription will bake these rules into its documents so header-ignoring clients still get routing. * feat(sub): bake Happ/INCY routing profiles into JSON subscription documents When subJsonRoutingRules is set, every emitted document (per-inbound and balancer alike) carries the profile's dns and routing rules baked in, so header-ignoring clients like Happ and INCY still get routing; the legacy simple-rules merge only applies when no profile is set. The balancer document builder keeps rewriting proxy-tag rules to the balancer. * feat(sub): add the subJsonRoutingRules setting Plumbed from the settings store through the subscription server into SubJsonService, so admins can set a routing profile once and every JSON subscription document carries it. * chore(api): regenerate OpenAPI artifacts for subJsonRoutingRules * feat(web): routing profile editor for the JSON subscription A textarea inside the JSON card accepts the routing profile (inline JSON, happ/incy deeplink, or https URL) with a remote-source badge; the badge helper moves to a shared module. Keys added to all 13 locales. * fix(sub): warm and lazily resolve the baked JSON routing source The routing profile was resolved once at service construction: a remote URL that was cold at that moment baked default routing forever, and the cron job never warmed it. The job now warms the subJsonRoutingRules URL, and the profile resolves per request with an in-memory memo (a failed resolve is not cached), so a warmed cache takes effect without a restart. * feat(sub): fall back to the JSON routing profile for the Routing header Happ and INCY download the geo files a routing profile references through the Routing response header. When the Happ header setting was blank the header stayed unset, and clients fetched no geo files even though a JSON routing profile was configured. A blank setting now falls back to the JSON profile: happ/incy deeplinks pass through, inline JSON and remote URLs are normalized to a happ:// deeplink; an unusable or oversized value leaves the header unset. Locale captions mention the fallback. * fix(sub): pass routingRules arg at call sites added by main Main gained four NewSubJsonService call sites after this branch forked; update them to the five-arg signature so internal/sub builds again. * fix(sub): address code review findings on the baked JSON routing The memoised baked template never invalidated, so an edited remote profile kept serving the superseded dns/routing subtrees until a panel restart; bakedTemplate now re-resolves the spec per request and rebuilds only when the payload actually changed (regression-tested). subJsonRoutingRules shared the happ persistence row with subRoutingRules, so only the last-written setting survived a restart; it now resolves under its own jsonhapp kind with the same validation and size caps. The setting also joins validateSettingsURLs, so remote values are canonicalised and bad URLs are rejected on save. Also: drop the unreachable half of the remote-source guard, cut the overlong comment blocks to the two-line convention, and deduplicate remoteSourceBadge in the General tab. Merges upstream/main (call sites for the widened NewSubJsonService signature). * style(sub): gofumpt the json_routing imports * fix(sub): accept happ add/ deeplinks and bound the routing warning The baked-JSON routing parser only recognised happ://routing/onadd/, but normalizeHappRouting treats happ://routing/add/ as an equally valid routing deeplink. An operator pasting the add/ form got the Routing header set, so the panel looked configured, while every JSON subscription document silently carried the default routing instead of their profile. resolveJsonRoutingSpec logged one warning per call and bakedTemplate calls it once per emitted document, so a single fetch of an unusable profile wrote one identical warning per document. On the public subscription server that floods the 10240-entry buffer the panel's log view reads, evicting real entries. Log only when the message changes, and reset on a successful resolve so a profile that recovers and fails again is still reported. Also resolve the template once in buildBalancerConfig: two resolves could straddle a profile refresh and pair one revision's dns with the other's routing.
3x-ui Documentation
The official documentation and product site for 3x-ui — an advanced web panel for managing Xray-core servers.
Overview
This directory (docs/ in the 3x-ui monorepo) contains
the source for docs.sanaei.dev — a static-first documentation and
marketing site built with Fumadocs on Next.js. It has no backend,
no database, and no auth: every page is prerendered and every tool runs entirely in the
browser.
What's inside
The documentation walks you through 3x-ui from first install to day-to-day operation:
- Getting Started — installation, first login, and updating or uninstalling the panel.
- Configuration — the panel, inbounds, REALITY, transports, clients, subscriptions, and share links.
- Operations — reverse proxy, multi-node setups, outbounds & routing, backup/restore, the Telegram bot, and security.
- Reference — environment variables, the database, ports & firewall, and the HTTP API.
- Help — troubleshooting, FAQ, migration, and how to contribute.
Interactive tools
The site ships with in-browser helpers that generate configuration for you — no data ever leaves your browser:
| Tool | What it does |
|---|---|
| REALITY Config Generator | Build a valid REALITY inbound configuration. |
| Share Link Inspector | Decode and inspect vless:// / vmess:// share links. |
| Install Command Builder | Assemble the right install command for your setup. |
| Reverse Proxy Generator | Generate reverse-proxy configs (Nginx / Caddy). |
| Protocol Wizard | Pick and configure the right protocol for your needs. |
| Firewall Rules Generator | Produce firewall rules for your ports. |
Tech stack
| Layer | Technology |
|---|---|
| Framework | Next.js 16 (App Router) · React 19 |
| Docs | Fumadocs (-ui / -core / -mdx) |
| Styling | Tailwind CSS v4 |
| Search | Orama static index |
| Language | TypeScript (strict) |
| Tests | Vitest for the pure lib/xray logic |
| Tooling | pnpm · oxlint · oxfmt |
Quick start
This project uses pnpm (npm lockfiles are gitignored). Run everything
from the docs/ directory:
cd docs
pnpm install
pnpm dev # http://localhost:3000
Useful scripts:
| Script | Description |
|---|---|
pnpm dev |
Start the dev server |
pnpm build |
Production build (also typechecks) |
pnpm typecheck |
Generate MDX/route types and tsc --noEmit |
pnpm lint |
Run oxlint (.oxlintrc.json) |
pnpm test |
Run unit tests (Vitest) |
See CONTRIBUTING.md for the full list and project conventions.
Project structure
app/ # Next.js App Router — layouts, home, docs, OG images, search, llms.txt
components/ # React components — interactive tools, home sections, MDX bindings
content/docs/ # MDX documentation, one folder per locale (en · fa · ru · zh)
lib/ # source config, i18n, GitHub stats, and the unit-tested lib/xray logic
public/ # static assets — logos, favicon, openapi.json, CNAME
scripts/ # build-time scripts (API reference generation)
source.config.ts # Fumadocs MDX schema & collection config
next.config.mjs # Next.js config (static-export gating)
proxy.ts # i18n middleware
Internationalization
Documentation is authored in English. Persian (fa, RTL), Russian (ru), and
Chinese (zh) locales are wired up; untranslated pages fall back to English so they
never 404. English URLs are unprefixed; other locales live under /fa, /ru, /zh.
Deployment
The site builds for two targets:
- Vercel / Node —
pnpm build(static search index + prerendered OG images). - GitHub Pages (static export) —
DEPLOY_TARGET=static pnpm build→out/.
Contributing
Contributions are welcome! Setup, scripts, and project conventions live in
CONTRIBUTING.md.
License
Licensed under GPL-3.0.