Epic — parked deliberately. Opened to record the gap and the reasoning, not to be worked on yet.
Every way into gori today requires the client's cooperation or the network's:
| Path |
Requires |
| forward proxy |
the client honours proxy settings |
| transparent listener |
a kernel redirect rule (pf / iptables), plus the caveats in the transparent-completion issue |
upstream chaining (settings/upstream_rules.cr) |
gori is the client, not the server |
A large and growing class of targets satisfies none of these: mobile apps that ignore system proxy settings, desktop agents and auto-updaters, anything using a hardcoded transport. For those, gori currently has no answer. TLS passthrough (settings/network.cr:29-40) lets such an app keep working through the proxy, but by definition shows nothing.
Candidate approaches, roughly by cost
- SOCKS5 server mode. gori already speaks SOCKS5 as a client (
settings/upstream_rules.cr:15), so the protocol is partly understood in-tree. Server mode is a different socket lifecycle, but it is the smallest of these. Reaches any client that supports SOCKS even when it ignores HTTP proxy settings.
- Local capture with process filtering. Intercept by originating process rather than by network path. Highest practical value — it is the only one that solves "this one app on this machine" without touching global network state. Also the most platform-specific: a different mechanism per OS, all of them privileged or near-privileged.
- WireGuard mode. Run a VPN endpoint; clients connect as standard WireGuard peers and their traffic is intercepted. Reaches phones and other devices without root on the device or changes to its proxy settings. Needs a WireGuard implementation, which in Crystal means FFI or writing one.
- TUN interface. Virtual interface, route traffic through it. Linux, root.
Adjacent, same drawer
Non-HTTP traffic. Today TLS passthrough is the only option and it is blind — the bytes are relayed without decryption or capture. Raw TCP, TCP-over-TLS, UDP and DTLS interception would let gori see custom binary protocols, MQTT, and similar. It is a real limitation: an engagement that turns out to involve a non-HTTP protocol requires switching tools entirely.
Whether this belongs in gori is a genuine product question. gori is an HTTP workbench, and "capture arbitrary bytes" is a different tool's job — but the boundary is worth deciding on purpose rather than by omission.
Why parked
Each of these is a multi-week, platform-specific, privilege-requiring subsystem, and each expands the maintenance and security surface substantially. None should start before there is evidence of demand, and before the reverse-mode and transparent-completion work has shown how far the cheap paths actually get.
Revisit when: a concrete engagement is blocked by this, or the cheaper listener work lands and demand persists.
If one gets picked up first, it should be SOCKS5 server mode — smallest, most in-tree precedent, and it degrades gracefully (a client that cannot do SOCKS is no worse off than today).
Epic — parked deliberately. Opened to record the gap and the reasoning, not to be worked on yet.
Every way into gori today requires the client's cooperation or the network's:
settings/upstream_rules.cr)A large and growing class of targets satisfies none of these: mobile apps that ignore system proxy settings, desktop agents and auto-updaters, anything using a hardcoded transport. For those, gori currently has no answer. TLS passthrough (
settings/network.cr:29-40) lets such an app keep working through the proxy, but by definition shows nothing.Candidate approaches, roughly by cost
settings/upstream_rules.cr:15), so the protocol is partly understood in-tree. Server mode is a different socket lifecycle, but it is the smallest of these. Reaches any client that supports SOCKS even when it ignores HTTP proxy settings.Adjacent, same drawer
Non-HTTP traffic. Today TLS passthrough is the only option and it is blind — the bytes are relayed without decryption or capture. Raw TCP, TCP-over-TLS, UDP and DTLS interception would let gori see custom binary protocols, MQTT, and similar. It is a real limitation: an engagement that turns out to involve a non-HTTP protocol requires switching tools entirely.
Whether this belongs in gori is a genuine product question. gori is an HTTP workbench, and "capture arbitrary bytes" is a different tool's job — but the boundary is worth deciding on purpose rather than by omission.
Why parked
Each of these is a multi-week, platform-specific, privilege-requiring subsystem, and each expands the maintenance and security surface substantially. None should start before there is evidence of demand, and before the reverse-mode and transparent-completion work has shown how far the cheap paths actually get.
Revisit when: a concrete engagement is blocked by this, or the cheaper listener work lands and demand persists.
If one gets picked up first, it should be SOCKS5 server mode — smallest, most in-tree precedent, and it degrades gracefully (a client that cannot do SOCKS is no worse off than today).