Local Sandbox startup fails: proxy-everything exits with 'setsockoptint: protocol not available' and Sandbox DO loops on 'No such container'

[levi]

Summary

Local Sandbox startup fails on a minimal repro. The worker image builds successfully, but the request never reaches sandbox.exec(...) because the local proxy sidecar exits immediately and the Sandbox DO keeps retrying with:

Monitoring container failed with: 404 {"message":"No such container: workerd-cf-sandbox-minimal-Sandbox-..."}

The matching Docker proxy container exits with:

Fatal error:  setsockoptint: protocol not available

Minimal repro

Gist: https://gist.github.com/levi/186e349098b047bd95ceb8f9fac8328f

Key files:

• package.json
• wrangler.jsonc
• src/index.ts
• Dockerfile

Environment

• macOS 15.3.0 (Darwin 25.3.0, arm64)
• Bun 1.3.11
• Node v20.20.1
• Wrangler 4.77.0
• Docker 28.5.2
• Docker context: orbstack

Steps to reproduce

1. bun install
2. bun run dev
3. In another terminal, curl -i http://localhost:8787/run

Expected behavior

GET /run should start the sandbox and return a JSON response containing:

hello from sandbox

Actual behavior

Wrangler starts successfully and reports the container image is ready. On the first request:

Uncaught Error: Network connection lost.
Monitoring container failed with: 404 {"message":"No such container: workerd-cf-sandbox-minimal-Sandbox-..."}
Container not ready, retrying

Docker shows the proxy sidecar for the sandbox exits immediately:

$ docker ps -a --format '{{.Names}}\t{{.Image}}\t{{.Status}}' | rg 'cf-sandbox-minimal|proxy-everything'
workerd-cf-sandbox-minimal-Sandbox-82533a8f52203aacd7ef6c91eb3b563c2d705983acae9f18f6de6658a4ce18ac-proxy  cloudflare/proxy-everything:3cb1195  Exited (1)

$ docker logs workerd-cf-sandbox-minimal-Sandbox-82533a8f52203aacd7ef6c91eb3b563c2d705983acae9f18f6de6658a4ce18ac-proxy
Fatal error:  setsockoptint: protocol not available

The docker inspect for that proxy container shows it is launched with CapAdd: ["NET_ADMIN"].

Repro source

src/index.ts

import {
  getSandbox,
  type Sandbox as SandboxType,
  proxyToSandbox,
  Sandbox,
} from "@cloudflare/sandbox";

type Env = {
  Sandbox: DurableObjectNamespace<SandboxType>;
};

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const proxyResponse = await proxyToSandbox(request, env);
    if (proxyResponse) {
      return proxyResponse;
    }

    const url = new URL(request.url);

    if (url.pathname === "/run") {
      const sandbox = getSandbox(env.Sandbox, "minimal-test");

      await sandbox.setEnvVars({
        NODE_ENV: "production",
      });

      const result = await sandbox.exec("echo hello from sandbox");

      return Response.json({
        success: result.success,
        stdout: result.stdout,
        stderr: result.stderr,
        exitCode: result.exitCode,
      });
    }

    return new Response("Try GET /run");
  },
} satisfies ExportedHandler<Env>;

export { Sandbox };

wrangler.jsonc

{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "cf-sandbox-minimal",
  "main": "src/index.ts",
  "compatibility_date": "2026-03-17",
  "compatibility_flags": [
    "nodejs_compat",
    "nodejs_compat_populate_process_env"
  ],
  "containers": [
    {
      "class_name": "Sandbox",
      "image": "./Dockerfile"
    }
  ],
  "durable_objects": {
    "bindings": [
      {
        "name": "Sandbox",
        "class_name": "Sandbox"
      }
    ]
  },
  "migrations": [
    {
      "tag": "v1",
      "new_sqlite_classes": [
        "Sandbox"
      ]
    }
  ]
}

Dockerfile

FROM docker.io/cloudflare/sandbox:0.7.20

WORKDIR /workspace

Notes

• This reproduces outside my application code.
• I also reproduced the same failure in a larger app using both WebSocket and HTTP transport modes locally; the minimal repro above does not depend on any custom application setup.

[levi]

Retested the minimal repro on a second local Docker engine and saw the same failure, so this does not appear to be OrbStack-specific.

Environment:

• Colima 0.10.1
• Docker context: colima
• Docker server OS: Ubuntu 24.04.4 LTS
• Kernel: 6.8.0-100-generic

Result:

• wrangler dev starts successfully
• GET /run hangs until timeout
• Sandbox DO logs the same retry loop: Monitoring container failed with: 404 {"message":"No such container ..."}
• The cloudflare/proxy-everything:3cb1195 sidecar exits immediately with the same log:
  • Fatal error: setsockoptint: protocol not available

So the minimal repro now fails the same way on both OrbStack and Colima on this machine.

[levi]

Root cause isolated on arm64 hosts.

Wrangler 4.77.0 pulls and launches the egress interceptor as:

• cloudflare/proxy-everything:3cb1195@sha256:0ef6716c52430096900b150d84a3302057d6cd2319dae7987128c85d0733e3c8

That digest is the multi-arch index digest, not the arm64 leaf manifest digest. On this arm64 machine, running that exact ref manually resolves to linux/amd64 and reproduces the same crash immediately:

• WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8)
• Fatal error: setsockoptint: protocol not available

By contrast:

• docker run cloudflare/proxy-everything:3cb1195 ... works
• docker run cloudflare/proxy-everything:3cb1195@sha256:78c7910f4575a511d928d7824b1cbcaec6b7c4bf4dbb3fafaeeae3104030e73c ... works
  • sha256:78c7910f... is the arm64 leaf manifest from docker manifest inspect cloudflare/proxy-everything:3cb1195

Relevant Wrangler code in my local install:

• node_modules/wrangler/wrangler-dist/cli.js
• pullEgressInterceptorImage() calls docker pull <image> --platform linux/amd64
• DEFAULT_CONTAINER_EGRESS_INTERCEPTOR_IMAGE is set to the multi-arch index digest above

Local workaround that makes the repro pass here:

• set MINIFLARE_CONTAINER_EGRESS_IMAGE=cloudflare/proxy-everything:3cb1195@sha256:78c7910f4575a511d928d7824b1cbcaec6b7c4bf4dbb3fafaeeae3104030e73c before wrangler dev

With that override, the standalone repro returns 200 and successfully runs the sandbox command.

[hugentobler]

Had same issue, author's solution worked perfectly.

"scripts": {
  "dev": "MINIFLARE_CONTAINER_EGRESS_IMAGE=cloudflare/proxy-everything:3cb1195@sha256:78c7910f4575a511d928d7824b1cbcaec6b7c4bf4dbb3fafaeeae3104030e73c wrangler dev",
  "deploy": "wrangler deploy"
}

[JiwaniZakir]

The setsockoptint: protocol not available error from the proxy-everything container is a Go-level syscall failure when attempting to set a socket option that the kernel doesn't support — most likely IP_TRANSPARENT (used for transparent proxying), which requires CONFIG_NETFILTER_XT_TARGET_TPROXY or equivalent kernel support. OrbStack uses its own lightweight Linux VM kernel that may not ship with the netfilter/tproxy modules that Docker Desktop's VM includes, so even though NET_ADMIN is granted via CapAdd, the underlying socket option call still fails at the kernel level. The fix would need to be in whatever code inside proxy-everything calls setsockopt — either falling back gracefully when IP_TRANSPARENT is unavailable, or detecting the OrbStack context and using a different proxying strategy that doesn't rely on tproxy semantics.

[nfarina]

Thank you @levi!! This fixed my Cloudflare Sandbox local setup using OrbStack. I was really really not looking forward to installing "real docker."

[eashish93]

Reproduced on Colima as well. Adding data points:

• OrbStack (default settings, macOS 15.x arm64): proxy-everything crashes with setsockoptint: protocol not available.

• OrbStack + Rosetta enabled: same crash. Rosetta doesn't expose the missing syscall.

• Colima 0.10.1 (vmType=vz, mountType=virtiofs, default kernel): same crash. Lima's bundled kernel also lacks TPROXY/IP_TRANSPARENT.

• Docker Desktop: untested (avoiding install) but per docs and #12965, this is the only validated engine.

• Cross-ref: workers-sdk#12965 (same error on Podman). The pattern is "any lightweight Docker runtime without TPROXY in its bundled kernel breaks proxy-everything." A small fix would be: ship a docs note explicitly listing OrbStack/Colima/Podman as incompatible, and surface a clearer error than outcome: 'unrecognized_error' so users don't burn hours on it.

[PClmnt]

Having the same issue and the fix proposed by @levi fixes this.