This isolated checkout contains the Rust rewrite in progress. Its Rust executable uses conditional native admission with no simulator fallback; the Go source below remains the product reference. Native implementation does not establish exact-candidate live qualification.
SBXR is a root-only V3 proxy product for one Ubuntu Server. Software Lifecycle installs the sbxr executable and retains recovery for existing durable transactions. Proxy Installation owns the installed proxy journey through a review-first numbered menu.
The source implements setup and removal, subscription enablement and link rotation, Client Identity rotation, and recovery. Newly enabled subscriptions use HTTP. The current release direction is clean installation only; existing installations use their exact release for reviewed removal and removal recovery. Implementation and automated tests do not establish release acceptance. Use ADR-0016 for the product contract and the current HTTP live acceptance procedure for live qualification.
For development, start with the code map. It links entry points, owning modules, tests, and the release harness. Domain terms are defined in CONTEXT.md. The documentation index separates the current MVP procedure from historical acceptance material and research notes.
- Ubuntu Server 24.04; the first V3 proxy journey accepts only
amd64 - Root authority through
sudo - An interactive UTF-8 terminal
curlfor the first GitHub HTTPS download
Software Lifecycle owns /usr/local/bin/sbxr and /var/lib/sbxr/installed.json.
Confirmed V3 setup creates the Proxy Installation resources recorded in
/var/lib/sbxr/proxy-ownership.json; reviewed Complete removal uses that authority
to remove the installation. See the Proxy Installation guide
for setup, subscription, identity, and removal responsibilities.
Use the permanent Pasteable Install Command:
curl -fsSL https://github.com/albertloky/SBXR/releases/latest/download/install.sh | sudo bashThis command selects the published Latest, not unpublished checkout changes. The command supports only the fixed host contract above. It authenticates and verifies the complete candidate before it changes either owned path. A current valid installation is a no-op. A higher-sequence local installation is not downgraded. A proved historical full-product executable from v1.0.0 through v1.0.15 is refused unchanged.
Run the installed product with no arguments:
sudo sbxrEvery screen shows fresh proxy, subscription, and Software Lifecycle status.
The same menu lists legal Proxy Installation Actions plus Check and Recover.
New software updates are unsupported and Update is absent from the menu.
Recover retains proved transaction recovery; it does not
start legacy transport migration. Only y approves a supported action's effects.
At an action confirmation, empty input or n cancels. Changed facts require a
fresh review.
Start setup opens a short numbered wizard. Press Enter for Standard
(no domain needed), or choose Standard + Cloudflare for your own hostname
and dedicated tunnel. h explains the connection types. b goes Back while
preserving the current draft; c cancels before Apply without installing anything.
At Apply setup? [y/N], Enter means No. Only y starts installation.
Follow the VMess Tunnel setup guide first. You need your own Cloudflare domain, an unused hostname and a dedicated remotely managed tunnel. The menu explains how to create/select that tunnel and checks its protected local prerequisites before confirmation. Standard keeps the existing VLESS REALITY Vision behavior and needs no hostname. Standard + Cloudflare adds VMess without changing that default connection.
The optional setup adds VMess on 127.0.0.1:10000, WebSocket path
/sbxr-vmess. SBXR manages only a dedicated sbxr-tunnel.service, using an
Owner-installed official cloudflared binary and a protected token file. It
does not create or change Cloudflare account resources, domain, tunnel or DNS.
The selected tunnel must forward the hostname to http://127.0.0.1:10000.
Clients use TLS on the hostname's TCP 443; no extra public origin port is needed.
Existing connector services are preserved. Tokens never belong in the hostname
prompt, client configuration, shell command arguments or reports.
The HTTP subscription includes the existing VLESS node and an additional VMess node. Both use one Client Identity; rotation replaces both credentials together. Show client configuration includes both outbounds, with VLESS still the default. Setup checks the public WebSocket route and authenticated VMess-only HTTPS traffic. A failure reports VMess connection pending, even if the local proxy is Running. After correcting the route, choose Check VMess connection; reinstallation is unnecessary. A server-originated pass does not prove outside-client or Karing acceptance. Complete removal stops and removes only SBXR's dedicated connector unit/link and local proxy resources. The Owner's token, cloudflared package, domain, tunnel and DNS remain the Owner's responsibility.
This is source implementation, not a published or live-qualified release. VMess can be selected only before proxy setup; there is no in-place enable action, including for an existing VLESS-only installation. To switch, finish reviewed Complete removal through the installed exact release, clean-install a qualified VMess-capable release, and select the VMess setup variant. This entails downtime, new client credentials, a new Subscription Link and client reconfiguration.
New subscriptions use http://<recorded IPv4>:8443/s/<token>. They need provider
TCP 8443 access and create no Let's Encrypt certificate, Certbot dependency or
TCP 80 challenge rule. Token authentication and protected local files remain.
HTTP exposes the link and downloaded proxy credentials to interception and
permits tampering; the confirmation plan discloses this risk. The VLESS/REALITY
proxy on TCP 443 and software signature/attestation checks remain unchanged.
Automatic legacy HTTPS migration is disabled. Historical HTTPS repair and cleanup authority remain available to their exact-release recovery paths; they are not incoming-upgrade support. See ADR-0028.
Release support is subscription-clean-install-only, with an explicit empty
incoming source list. To replace an existing installation, use that release's
reviewed Complete removal, finish an interrupted removal through its exact-release
route, then install and set up fresh. This entails downtime, new proxy credentials
and new client setup. The installer refuses remaining authority or resources and
retains exact removal-finisher restoration. An already absent host needs no old
source installation or removal.
There is no background software updater or Update menu action. Existing transaction rollback/forward completion, installation recovery, proxy/subscription operation recovery and Complete removal keep their original proved directions. Local regression tests do not establish a live release.
Each release has exactly four public assets:
install.sh
release-index.json
sbxr-linux-amd64.tar.gz
sbxr-linux-arm64.tar.gz
Stable publication requires native automated proof on both architectures and
the live packaged Ubuntu Server 24.04 amd64 journeys for the candidate's
declared scope, including required outside-network and actual Karing evidence.
Each Release Identity gets its own public Acceptance Record.
The current scope uses mvp-http-live-v1: mvp-install, mvp-subscription,
mvp-credentials, mvp-serving, and mvp-removal, in that order. See the
HTTP live procedure. It requires no
source setup, source update/recovery journey or subscription certificate issuance.
Applicable recovery regressions remain ordinary tests. Historical repair and
HTTPS/recurring policies retain their original interpretation.
Before recommending Latest, prove refusal by the unchanged old updater and the installer over existing state. Without that proof, keep the candidate non-Latest; passing the five journeys alone cannot establish update compatibility.
The former V4 operator producer, its 25-scenario procedure, and its evidence guides are historical for their named attempts. The producer is retired from the working tree; historical Go readers and validators remain so existing records retain their meaning. Dated reports in docs/acceptance describe individual attempts. The Installer-Updater release-pair procedure is also historical.
v3.1.0 / Release Sequence 83 has an
Owner-approved exception with
incomplete live VPS and Karing qualification. It applies only to that release.
v3.1.81 / Release Sequence 159 was
published stable on 2026-09-25.
Its separate bounded exception
reuses prior v3.1.80 live evidence and late Owner confirmation; no fresh live run
was performed. The failed v3.1.80 qualification remains burned.
Releases v1.0.0 through v1.0.15 remain public, immutable, unsupported history. Their final source is preserved by annotated tag archive/full-product-v1.0.15 at commit 14fdf0a3decb6c653f9669438bf40221813b9d7d. They are not installation, update, migration, recovery, compatibility, or qualification inputs for the Installer-Updater.