Skip to content

feat(sandbox): log connection attempts that bypass proxy path #268

@pimlock

Description

@pimlock

Problem

When a process inside a sandbox attempts an outbound connection without going through the configured HTTP proxy path, we currently get poor observability.

In a recent openclaw-local debugging session, OpenClaw's Node fetch() failed with fetch failed / UND_ERR_CONNECT_TIMEOUT while curl to the same https://inference.local/... endpoint succeeded. The difference was that curl honored the sandbox proxy environment automatically, while Node fetch() required NODE_USE_ENV_PROXY=1.

Because the failing path did not produce useful OpenShell connection logs, it was hard to tell whether the app:

  • never emitted traffic
  • attempted a direct socket connection
  • bypassed the proxy path
  • was blocked before the request reached the normal logging path

John suggested that seccomp may be a good place to catch the socket attempt before we block it.

Requested change

Add sandbox-level diagnostics for outbound connection attempts that do not go through the expected proxy path.

The main goal is to surface enough information to debug cases where application networking fails before normal proxy / connection logs appear.

What to log

At minimum, when feasible, log:

  • process / binary identity
  • destination address and port requested by the process
  • whether the connection was direct vs proxy-mediated
  • reason the attempt was blocked or considered invalid
  • enough correlation data to tie the event back to a sandbox and process

Possible implementation direction

Investigate whether seccomp can intercept socket / connect attempts early enough to log them before denial, especially for direct connections that bypass the proxy path.

Acceptance criteria

  • A direct connection attempt from inside a sandbox that does not use the proxy path produces an observable diagnostic event
  • The diagnostic includes destination and process identity
  • The event is visible through existing sandbox / gateway logging surfaces, or a clearly documented new surface
  • The logs make it obvious why a request like fetch failed produced no normal connection log

Repro context

Inside sandbox openclaw-local:

This suggests we need better observability for connection attempts that never enter the expected proxy/logging path.

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions