[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-83408":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":9,"language":10,"languages":9,"totalLinesOfCode":9,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":15,"subscribersCount":15,"size":15,"stars1d":16,"stars7d":17,"stars30d":17,"stars90d":15,"forks30d":15,"starsTrendScore":18,"compositeScore":19,"rankGlobal":9,"rankLanguage":9,"license":9,"archived":20,"fork":20,"defaultBranch":21,"hasWiki":22,"hasPages":20,"topics":23,"createdAt":9,"pushedAt":9,"updatedAt":24,"readmeContent":25,"aiSummary":9,"trendingCount":15,"starSnapshotCount":15,"syncStatus":26,"lastSyncTime":27,"discoverSource":28},83408,"WhiteDNS-Wizard","iampedii\u002FWhiteDNS-Wizard","iampedii","Cloudflare-first WhiteDNS CLI\u002FTUI for provisioning a managed 3x-ui\u002FXray VPN stack over SSH, with DNS, certificates, client import links, Tor-routed profiles, diagnostics, backups, and repair\u002Freset flows.",null,"Go",189,16,60,5,0,15,106,101,3.69,false,"main",true,[],"2026-06-12 02:04:34","\u003Cp align=\"center\">\n  \u003Cimg src=\"assets\u002Fwhitedns-logo.png\" alt=\"WhiteDNS logo\" width=\"220\">\n\u003C\u002Fp>\n\n# WhiteDNS 3X-UI Wizard\n[Telegram: @whitedns](https:\u002F\u002Ft.me\u002F@whitedns)\n\nWhiteDNS is a Cloudflare-first provisioning wizard for setting up a managed 3x-ui\u002FXray VPN stack on a VPS. It runs locally, connects to the VPS over SSH, manages Cloudflare DNS and certificates, installs or repairs a Docker-based 3x-ui stack, and generates copyable client import strings.\n\nThe wizard focuses on a practical default setup:\n\n- Cloudflare-proxied WebSocket TLS profiles.\n- DNS-only direct profiles for protocols Cloudflare proxy cannot handle.\n- Server-side Tor exit variants users can import separately.\n- A managed 3x-ui Docker stack with PostgreSQL.\n- Encrypted local project secrets and repeatable reset\u002Frepair flows.\n\n## Quick Start\n\n### 1. Build the binary\n\n```bash\ngo build -o whitedns .\u002Fcmd\u002Fwhitedns\n```\n\n### 2. Run the interactive wizard\n\n```bash\n.\u002Fwhitedns\n```\n\nThe root command opens the menu. Select:\n\n```text\n0) Init setup\n```\n\nThe wizard will ask for:\n\n- Cloudflare account ID.\n- Cloudflare API token.\n- Domain name.\n- VPS IPv4 address.\n- SSH host, user, key\u002Fpassphrase, or password.\n\n### 3. Cloudflare token permissions\n\nCreate an Account API token in Cloudflare:\n\n1. Go to `Manage Account > Account API Tokens > Create Token`.\n2. Choose the `Edit zone DNS` template.\n\n![Choose the Edit zone DNS token template](assets\u002Ftutorial\u002Fcloudflare-edit-zone-dns-template.png)\n\n3. Scope it to the target domain when possible. Use all domains only when needed.\n4. Keep `DNS: Read + Edit`.\n5. In `DNS & Zones`, add `Zone: Read` and `Zone Settings: Edit`.\n\n![Cloudflare DNS and Zone permissions](assets\u002Ftutorial\u002Fcloudflare-dns-zone-permissions.png)\n\n6. In `Cache & Performance`, add `Zone SSL & Certificates: Edit`.\n\n![Cloudflare SSL and Certificates permission](assets\u002Ftutorial\u002Fcloudflare-ssl-certificates-permission.png)\n\nThe final required permissions are:\n\n```text\nDNS & Zones \u002F DNS: Read + Edit\nDNS & Zones \u002F Zone: Read\nDNS & Zones \u002F Zone Settings: Edit\nCache & Performance \u002F Zone SSL & Certificates: Edit\n```\n\nCloudflare API docs may call `Edit` permissions `Write`. WhiteDNS uses the account ID you enter for:\n\n```text\nGET \u002Fclient\u002Fv4\u002Faccounts\u002F\u003Caccount-id>\u002Ftokens\u002Fverify\n```\n\nTroubleshooting:\n\n| Error area | Usually means |\n| --- | --- |\n| Token validation | Wrong token, wrong account ID, expired\u002Fdisabled token, or incompatible token type. |\n| Zone lookup | Missing `Zone: Read` or token is not scoped to the selected domain. |\n| DNS or ACME DNS-01 | Missing `DNS: Edit`. |\n| SSL mode strict | Missing `Zone Settings: Edit`. |\n| Origin CA certificate | Missing `Zone SSL & Certificates: Edit`. |\n\n### 4. What the init flow does\n\nThe setup flow:\n\n- Validates the Cloudflare token.\n- Detects the Cloudflare zone.\n- Creates or updates DNS records.\n- Sets Cloudflare SSL mode to `strict`.\n- Creates a Cloudflare Origin CA certificate for proxied profiles.\n- Issues a public ACME wildcard certificate for DNS-only TLS profiles.\n- Installs or repairs managed Docker 3x-ui and PostgreSQL.\n- Adds a private Tor sidecar for Tor-profile outbound routing.\n- Replaces only WhiteDNS-managed inbounds\u002Foutbounds after confirmation.\n- Prints and saves client import strings.\n\n## DNS Records\n\nWhiteDNS creates these A records for the selected domain. Replace `\u003Cdomain>` and `\u003Cvps-ip>` with your real values.\n\n| Host | Type | Value | Proxy | Purpose |\n| --- | --- | --- | --- | --- |\n| `vpn.\u003Cdomain>` | A | `\u003Cvps-ip>` | Proxied | VLESS WS TLS through Cloudflare |\n| `trojan.\u003Cdomain>` | A | `\u003Cvps-ip>` | Proxied | VLESS WS TLS on 8443 through Cloudflare |\n| `panel.\u003Cdomain>` | A | `\u003Cvps-ip>` | DNS-only | 3x-ui dashboard |\n| `direct.\u003Cdomain>` | A | `\u003Cvps-ip>` | DNS-only | Direct VLESS TCP TLS |\n| `hy2.\u003Cdomain>` | A | `\u003Cvps-ip>` | DNS-only | Hysteria2 UDP |\n| `reality.\u003Cdomain>` | A | `\u003Cvps-ip>` | DNS-only | Reality TCP Vision |\n| `ss.\u003Cdomain>` | A | `\u003Cvps-ip>` | DNS-only | Shadowsocks 2022 |\n| `tor-vless-ws.\u003Cdomain>` | A | `\u003Cvps-ip>` | DNS-only | VLESS WS routed through Tor |\n| `tor-vless-ws-8443.\u003Cdomain>` | A | `\u003Cvps-ip>` | DNS-only | VLESS WS 8443 routed through Tor |\n| `tor-hy2.\u003Cdomain>` | A | `\u003Cvps-ip>` | DNS-only | Hysteria2 routed through Tor |\n| `tor-direct.\u003Cdomain>` | A | `\u003Cvps-ip>` | DNS-only | Direct VLESS routed through Tor |\n| `tor-reality.\u003Cdomain>` | A | `\u003Cvps-ip>` | DNS-only | Reality TCP Vision routed through Tor |\n| `tor-ss.\u003Cdomain>` | A | `\u003Cvps-ip>` | DNS-only | Shadowsocks routed through Tor |\n\nACME also creates temporary TXT records during public certificate issuance:\n\n```text\n_acme-challenge.\u003Cdomain>\n```\n\nThe app requests a wildcard certificate for `*.\u003Cdomain>`, so one challenge covers the DNS-only TLS hostnames.\n\n## Generated Client Profiles\n\nWhiteDNS creates import strings for:\n\n| Remark | Host | Port | Transport | Route |\n| --- | --- | --- | --- | --- |\n| `VLESS WS @whiteDNS` | `vpn.\u003Cdomain>` | `443\u002Ftcp` | WebSocket TLS | Cloudflare proxied |\n| `VLESS WS 8443 @whiteDNS` | `trojan.\u003Cdomain>` | `8443\u002Ftcp` | WebSocket TLS | Cloudflare proxied |\n| `Hysteria2 @whiteDNS` | `hy2.\u003Cdomain>` | `443\u002Fudp` | Hysteria2 TLS | Direct |\n| `Direct VLESS @whiteDNS` | `direct.\u003Cdomain>` | `2087\u002Ftcp` | TCP TLS | Direct |\n| `Reality TCP Vision @whiteDNS` | `reality.\u003Cdomain>` | `2083\u002Ftcp` | TCP Reality Vision | Direct |\n| `Shadowsocks @whiteDNS` | `ss.\u003Cdomain>` | `8388\u002Ftcp,udp` | Shadowsocks 2022 | Direct |\n| `VLESS WS Tor @whiteDNS` | `tor-vless-ws.\u003Cdomain>` | `2097\u002Ftcp` | WebSocket TLS | Server-side Tor exit |\n| `VLESS WS 8443 Tor @whiteDNS` | `tor-vless-ws-8443.\u003Cdomain>` | `2098\u002Ftcp` | WebSocket TLS | Server-side Tor exit |\n| `Hysteria2 Tor @whiteDNS` | `tor-hy2.\u003Cdomain>` | `2099\u002Fudp` | Hysteria2 TLS | Server-side Tor exit |\n| `Direct VLESS Tor @whiteDNS` | `tor-direct.\u003Cdomain>` | `2100\u002Ftcp` | TCP TLS | Server-side Tor exit |\n| `Reality TCP Vision Tor @whiteDNS` | `tor-reality.\u003Cdomain>` | `2101\u002Ftcp` | TCP Reality Vision | Server-side Tor exit |\n| `Shadowsocks Tor @whiteDNS` | `tor-ss.\u003Cdomain>` | `8390\u002Ftcp,udp` | Shadowsocks 2022 | Server-side Tor exit |\n\nReality profiles currently use either `apple.com` or `docker.com` as the saved SNI and Reality target. Normal TLS profiles keep their own hostnames as SNI so public certificate validation continues to work.\n\nTor profiles mean:\n\n```text\nclient -> VPS -> Tor -> destination\n```\n\nThe VPS still sees the client IP. Destination sites see the Tor exit IP. The Tor SOCKS service is internal to Docker and is not published as a public proxy.\n\nTor is TCP-oriented. UDP destination traffic from Tor Hysteria2 or Tor Shadowsocks profiles may fail rather than route through Tor.\n\n## Menu Items\n\nRun:\n\n```bash\n.\u002Fwhitedns\n```\n\nThe interactive menu provides:\n\n| Shortcut | Menu item | What it does |\n| --- | --- | --- |\n| `0` | Init setup | Runs the full setup flow: Cloudflare DNS\u002FSSL\u002FOrigin CA, local plans, SSH, Docker 3x-ui, certificates, inbounds, outbounds, clients, and import strings. |\n| `1` | Current setup info | Shows saved project details, VPS IP, zone status, DNS\u002Fprotocol plan summary, remote host, container name, last apply time, and client-links path. |\n| `2` | Diagnostics | Checks local files, certificates, DNS, Docker port publishing, Tor sidecar status, panel\u002FAPI access, Xray config, and common protocol issues. |\n| `3` | Repair installation | Re-ensures the managed Docker stack, uploads certificates, repairs\u002Frestarts 3x-ui, reapplies WhiteDNS-managed inbounds\u002Foutbounds, and regenerates links. |\n| `4` | Backup installation | Creates a local backup of the project files and a remote archive of the managed `\u002Fvar\u002Flib\u002Fwhitedns\u002F3x-ui` installation. |\n| `5` | Restore latest backup | Restores the latest available WhiteDNS backup for the selected project and managed remote installation. |\n| `6` | Support bundle | Writes a troubleshooting bundle with diagnostics, plans, state, logs, Docker status, 3x-ui logs, Tor logs, and relevant remote config snapshots. |\n| `7` | Get list of inbounds | Logs into the saved 3x-ui panel over SSH tunnel and lists inbound ID, state, remark, protocol, port, transport\u002Fsecurity, and client count. |\n| `8` | Get list of outbounds | Reads the Xray outbound config from 3x-ui and lists outbound tags\u002Fprotocols, including WhiteDNS direct, blocked, and Tor outbounds. |\n| `9` | Get list of clients (10 only) | Shows the first 10 clients across inbounds with inbound remark, email, enabled state, masked identifier, expiry, and traffic limit. |\n| `d` | Dashboard credentials and login info | Shows the public panel URL, username, password, base path, and private SSH tunnel fallback command. |\n| `c` | Change Cloudflare domain | Prompts for a new domain\u002FVPS IP, provisions Cloudflare for the new domain, reuses saved secrets where possible, and reapplies 3x-ui. |\n| `r` | Reset installation | Replaces WhiteDNS-managed inbounds\u002Foutbounds and reapplies the managed stack while preserving local secrets and client identities. |\n| `x` | Delete installation | Removes only WhiteDNS-managed remote inbounds\u002Foutbounds and managed stack files when detected. Local project files are kept. |\n\nNavigation:\n\n- `esc` or `b` returns from submenus to the main menu.\n- `q` exits.\n- Destructive actions require typed confirmation.\n\n## CLI Commands\n\nThe interactive menu is the preferred workflow, but the CLI also exposes subcommands:\n\n```bash\n.\u002Fwhitedns cloudflare check --domain example.com\n.\u002Fwhitedns cloudflare apply --domain example.com --ip 1.2.3.4\n.\u002Fwhitedns plan show example.com\n.\u002Fwhitedns xui check --domain example.com --ssh-host 1.2.3.4\n.\u002Fwhitedns xui plan --domain example.com --ssh-host 1.2.3.4\n.\u002Fwhitedns xui apply --domain example.com --ssh-host 1.2.3.4 --yes\n```\n\nUseful XUI flags:\n\n```text\n--ssh-user root\n--ssh-port 22\n--ssh-key ~\u002F.ssh\u002Fid_ed25519\n--ssh-key-passphrase \u003Cpassphrase>\n--ssh-password \u003Cpassword>\n--panel-username \u003Cusername>\n--panel-password \u003Cpassword>\n--panel-base-path \u002Ftp-example\u002F\n--acme-email admin@example.com\n```\n\n## Output Files\n\nLocal project files are written under:\n\n```text\n~\u002F.wdns-wizard\u002Fprojects\u002F\u003Cdomain>\u002F\n```\n\nImportant files:\n\n```text\nconfig.yaml\nsecrets.enc.yaml\ncloudflare-state.json\nxui-state.json\nclient-links.yaml\norigin\u002Forigin.pem\norigin\u002Forigin.key\ncerts\u002Fpublic.pem\ncerts\u002Fpublic.key\nplans\u002Fdns-plan.yaml\nplans\u002Fprotocol-plan.yaml\nplans\u002Fxui-plan.yaml\nlogs\u002Fprovision-*.log\nlogs\u002Fxui-provision-*.log\n```\n\nRemote managed files are kept under:\n\n```text\n\u002Fvar\u002Flib\u002Fwhitedns\u002F3x-ui\u002F\n```\n\nOlder managed installs under `\u002Fopt\u002Fwdns-wizard\u002F3x-ui\u002F` are migrated to this path automatically when possible.\n\n## Privacy Policy\n\nWhiteDNS is a local CLI\u002FTUI tool. It does not include telemetry, analytics, tracking pixels, remote reporting, or a WhiteDNS-hosted backend.\n\n### What WhiteDNS stores locally\n\nWhiteDNS stores project data on the machine where you run the tool:\n\n```text\n~\u002F.wdns-wizard\u002Fprojects\u002F\u003Cdomain>\u002F\n```\n\nThis can include:\n\n- Domain, VPS IP, DNS\u002Fprotocol plans, state files, logs, and generated client import strings.\n- Cloudflare Origin CA certificate material.\n- Public ACME certificate material.\n- Encrypted secrets in `secrets.enc.yaml`.\n\nSecrets are encrypted locally using a key stored under the WhiteDNS root or provided through:\n\n```text\nWDNS_WIZARD_SECRETS_KEY\n```\n\nThe 3x-ui panel password, Cloudflare token, generated client IDs\u002Fpasswords, and protocol secrets are not intentionally written in plaintext logs. The Origin CA private key and public ACME private key are written as key files because the server needs them for TLS.\n\n### What WhiteDNS sends to third parties\n\nWhiteDNS communicates only with services needed for provisioning:\n\n- Cloudflare API: token validation, zone lookup, DNS records, SSL mode, Origin CA, and ACME DNS-01 TXT records.\n- Let's Encrypt ACME: public certificate issuance for `*.\u003Cdomain>`.\n- Your VPS over SSH: Docker installation, 3x-ui setup, certificates, inbounds, outbounds, diagnostics, backups, and support bundles.\n- Docker\u002FGitHub package endpoints when installing Docker Compose plugin fallback binaries.\n\nWhiteDNS does not sell, share, or upload your project data to a WhiteDNS service.\n\n### User responsibility\n\nYou control the Cloudflare account, VPS, generated clients, and local project files. Anyone with access to your local machine, project directory, VPS, 3x-ui dashboard, or client import strings may be able to access sensitive configuration.\n\nKeep these private:\n\n- Cloudflare API token and account ID.\n- `~\u002F.wdns-wizard` project directory.\n- `WDNS_WIZARD_SECRETS_KEY` or `.secrets.key`.\n- 3x-ui dashboard credentials.\n- Client import strings and private keys.\n\n## Build And Develop\n\n### Requirements\n\n- Go `1.24.2` or newer compatible toolchain.\n- SSH access to the VPS for live provisioning.\n- Docker-capable Linux VPS for the managed 3x-ui stack. If Docker exists but the Compose plugin is missing, WhiteDNS tries distro packages first, then falls back to the official Docker Compose v2 CLI plugin binary.\n- Cloudflare zone and API token.\n\n### Run tests\n\n```bash\ngo test .\u002F...\n```\n\nWhen using a local project cache:\n\n```bash\nenv GOCACHE=\"$PWD\u002F.cache\u002Fgo-build\" go test .\u002F...\n```\n\n### Build\n\n```bash\ngo build -o whitedns .\u002Fcmd\u002Fwhitedns\n```\n\n### Release builds\n\nGitHub Release builds are handled by:\n\n```text\n.github\u002Fworkflows\u002Frelease.yml\nscripts\u002Fbuild-release.sh\nscripts\u002Frelease-targets.txt\n```\n\nWhen a GitHub release is published, the workflow runs tests, builds archives for every target in `scripts\u002Frelease-targets.txt`, writes SHA-256 checksums, stores the files as a workflow artifact, and uploads the same files to the GitHub release.\n\nRun the release builder locally with:\n\n```bash\nVERSION=v0.1.0 .\u002Fscripts\u002Fbuild-release.sh\n```\n\nArtifacts are written to:\n\n```text\ndist\u002F\n```\n\nThe default targets include Linux, macOS, Windows, FreeBSD, OpenBSD, NetBSD, and Termux-compatible Android ARM64. The Termux build uses Go's `android` target and is named like:\n\n```text\nwhitedns_\u003Cversion>_termux-android-arm64.tar.gz\n```\n\n### Format\n\n```bash\nfind cmd internal pkg -name '*.go' -print0 | xargs -0 gofmt -w\n```\n\n### Development notes\n\n- Keep local state paths stable: `~\u002F.wdns-wizard\u002F...`.\n- Keep remote state paths stable: `\u002Fvar\u002Flib\u002Fwhitedns\u002F3x-ui\u002F...`.\n- Use the interactive menu for end-to-end testing.\n- Use `xui plan` before `xui apply` when testing conflict detection.\n- `reset` preserves local secrets and client identities.\n- `delete` removes only WhiteDNS-managed remote resources; local project files are kept.\n",2,"2026-06-11 04:11:05","CREATED_QUERY"]