feat(proxystatus): per-layer status ownership; move status.skysocks to skysocks-client - #4094
Merged
Merged
Conversation
…o skysocks-client Each resolving-proxy layer now owns exactly one reserved status host instead of every layer answering for all three. A new StatusSurface on the dmsgweb and skynetweb runtime Configs scopes serving to that surface: dmsg_web answers only status.dmsg, skynet_web only status.skynet. A matched status host for a different surface is not served — it falls through so the request continues up the chain to the layer that owns it. The owned host is now also served over HTTPS: status.dmsg / status.skynet are within the resolver CA name constraints, so the TLS-MITM path mints a per-host leaf and serves the page over terminated TLS, mirroring the existing MITM interstitial branch. status.skysocks moves to the skysocks-client, which is where it belongs: the resolver CA forbids a .skysocks leaf, so it must be served HTTP-only outside the MITM resolvers. The client transparently sniffs the SOCKS5 CONNECT target — forwarding the greeting/method negotiation and every non-status request to the exit byte-for-byte — and answers a status.skysocks CONNECT in-process. The page is rendered from the client's own session state (liveness + open stream count), since skysocks-client is a separate app process whose app RPC exposes no status query and adding cross-process plumbing wasn't warranted.
0pcom
force-pushed
the
feat/per-layer-status-providers
branch
from
August 22, 2026 23:59
05e51ce to
df0662c
Compare
0pcom
added a commit
that referenced
this pull request
Aug 23, 2026
…ks (#4125) #4094 moved status.skysocks serving into the skysocks-client's in-process handler but skipped the cross-process plumbing, so the page rendered only session liveness + open-stream count — the per-leg mux table, route/transport events and recent logs went empty even with a live route group. Add a read-only app->visor RPC (ProxyStatus) that returns the visor-built proxystatus.Snapshot, and have skysocks-client render that (overlaying its own live session Running/Note) instead of the minimal local snapshot. On RPC error or an empty snapshot it falls back to the local view, so status.skysocks still renders where the RPC is unavailable (e.g. the browser wasm-visor). Read-only addition; the data-plane splice and #4094's per-layer scoping for dmsg/skynet are untouched.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Each resolving-proxy layer now owns exactly one reserved status host instead of every layer answering for all three.
StatusSurfacefield on thedmsgweb/skynetwebruntimeConfig(checked right afterproxystatus.Match) makesdmsg_webserve onlystatus.dmsgandskynet_webserve onlystatus.skynet. A matched status host for a different surface is not served — it falls through so the request continues up the chain to the owning layer. Empty surface keeps the old serve-any behavior for standalone runtimes/tests.status.dmsg/status.skynetare within the resolver CA name constraints, so the TLS-MITM path mints a per-host leaf and serves the page over terminated TLS, mirroring the existing MITM interstitial branch.status.skysocksmoves to the skysocks-client. The resolver CA forbids a.skysocksleaf, so it must be HTTP-only and served outside the MITM resolvers. The client transparently sniffs the SOCKS5 CONNECT target — forwarding the greeting/method negotiation and every non-status request to the exit byte-for-byte — and answers astatus.skysocksCONNECT in-process. The snapshot is rendered from the client's own session state (liveness + open stream count), since skysocks-client is a separate app process whose app RPC exposes no status query.Existing HTTP
status.dmsg/status.skynet/status.skysockskeep working, now each from the right owner. Unit tests cover the scoping (a dmsg_web-scoped runtime servesstatus.dmsgbut fallsstatus.skynetthrough, and vice versa) and the skysocks-client interception (status served in-process, non-status forwarded to the exit).go build .,gofmt -l, andgo vetare clean on the changed packages.