feat(socks): auth-code/JWT login, network presets, reliability settings, control plane + web panel

[full-bars]

Summary

Adds three independent capabilities to the dev socks5 client, plus a metrics printer:

• Login methods. --auth-code redeems a code via /auth/code-login (for beta/test networks that have no password accounts, the same flow the provider CLI uses). --jwt skips login entirely and uses an existing network JWT directly. Password login (--user-auth + --password) remains the default and is unchanged.
• --network=main|beta preset (env NETWORK) resolves the matching api/platform URL pair. Explicit --api-url / --platform-url (or their env vars) override the preset per field.
• --reliability=<file> loads a partial JSON overlay of connect.ReliabilitySettings at startup. Durations are milliseconds in the file. A field absent from the file keeps the engine default; a field present with an explicit zero is applied. The overlay is merged onto the multi client's current settings, not applied standalone, so unset fields never get zeroed.
• --control=<addr> starts a local control plane, mirroring the Android app's developer screen. Its primary interface is a web panel; the same endpoints are also reachable over HTTP for scripting (see below). Binding is enforced to loopback at startup; a non-loopback --control address fails fast. Mutating requests additionally require either no Origin header or a loopback Origin, so a web page open in a browser cannot drive the plane cross-origin even though it is reachable on loopback.
• --metrics-every=<ms> prints reliability counters and the exit table to stdout on an interval; --reset-metrics zeroes the counters at startup.

Web panel

--control=127.0.0.1:9998 and open http://127.0.0.1:9998/ in a browser. The panel is a single embedded page (no external assets) that polls every 1s:

• a live measurements grid (flows opened, blast radius, recovery, probes, verdicts, rebinds, groups)
• a session header with elapsed time, cumulative traffic up/down, and live throughput rates (auto-scaled B/s to GiB/s, computed from /stats deltas)
• click-to-cycle preset knobs and toggles for every reliability setting, grouped the same way as the Android screen
• per-exit drop / stall / resume / migrate buttons, plus reset measurements, shuffle exits, and probe all

The panel layout, its knob groups, and the preset value lists are adapted from the developer tools screen in the URnetwork Beta Android app (the beta-test network's mobile client).

HTTP endpoints (fallback / scripting)

The panel talks to the same local HTTP API, which is also available directly:

• GET /settings — current settings, ms/json shape
• PUT /settings — partial reliabilityFile merged onto current settings (read-merge-write under a mutex)
• POST /actions — drop, stall, migrate, shuffle, probe-all, reset-metrics
• GET /metrics — reliability counters snapshot
• GET /exits — current exit table

Usage examples

All examples bind the SOCKS5 listener to loopback (127.0.0.1), which is
also the default when --addr is omitted. Use --addr 0.0.0.0:9999 only
when you deliberately want other devices on the LAN to reach the proxy —
note the proxy has no SOCKS5 authentication, so never bind it to a public
interface.

Password login against the main network (default, shown explicitly):

.\socks.exe --network=main --user-auth=user@example.com --password=password123

Auth-code login against beta:

.\socks.exe --network=beta --auth-code=eyJhbG...code

JWT login against beta, skipping login entirely:

.\socks.exe --network=beta --jwt=eyJhbG...yjwt

Explicit endpoints, overriding the network preset:

.\socks.exe --api-url=https://api.beta-test.net --platform-url=wss://connect.beta-test.net --auth-code=eyJhbG...code

Kitchen sink, on Windows (the control port is arbitrary; any free loopback
port works):

.\socks.exe --network=beta --auth-code=eyJhbG...code --metrics-every=5000 --reset-metrics --reliability=settings.json --control=127.0.0.1:9998

Example settings.json (partial overlay; only named fields change, everything else keeps the engine default):

{
  "maxFlowsPerExit": 64,
  "sendStallTimeoutMs": 3000,
  "busyProbe": true
}

Warning

The control server is unauthenticated by design. Loopback-only binding and the Origin guard stop remote machines and browser cross-origin requests, but they do not stop other local processes or users on a shared machine from reading and changing settings, dropping exits, or migrating flows. Do not expose --control beyond loopback and do not run it on a shared or multi-tenant host.

Verification

• Built for Linux and Windows and ran end to end against the beta network: auth-code login, jwt login, provider discovery, and contract establishment all succeeded. The Windows binary (socks.exe) was verified from PowerShell; the Linux build was used for the automated test suite.
• Exercised the control server and panel live: PUT /settings changed maxFlowsPerExit from 32 to 64 and the change was reflected on the next GET /settings; a non-loopback Origin header on a mutating request was rejected with 403; in the browser, cycling duration/count knobs and toggling switches in the panel produced the expected PUT /settings calls and updated values. The screenshot above was taken while the proxy was actively carrying traffic (flows opened 13, all pinned to one exit; probes 1379/753).
• 23 unit tests pass, race-clean (go test -race ./...).
• Package coverage: 62%.

Notes

Note

VerdictsHeldSharedFate (an Android-fork-only counter) is not present in upstream connect's ReliabilityMetricsSnapshot, so it is omitted from the metrics readout and the control panel's measurements grid. Everything else in the snapshot is surfaced.

• The socksproxy name in the CLI's own usage text is only the docopt usage label; the actual binary is socks (socks.exe on Windows).
• --reliability and the control server's PUT /settings share the same merge path (applyFileOver + fileToSettings), so file-based and live-tuned settings behave identically with respect to nil-keeps-default / explicit-zero-applies semantics.