Proxy Configuration & DNS Resolution

Network traffic from Codex microVMs routes through a host-side proxy that enforces allowlist rules, logs traffic metadata, and applies rate limits. The proxy operates at Layer 7 (HTTP/HTTPS) for web traffic and Layer 4 (TCP) for other protocols. HTTPS traffic uses CONNECT tunneling — the proxy sees the destination hostname (via SNI) but cannot inspect the encrypted payload. This means allowlist rules match on domain name, not URL path. You can allow or block api.example.com, but you cannot allow api.example.com/v2 while blocking api.example.com/v1.

DNS resolution inside the microVM uses a host-controlled resolver that enforces the allowlist at the DNS layer. Queries for allowlisted domains return real IP addresses. Queries for non-allowlisted domains return NXDOMAIN — the domain appears to not exist. This is faster and more secure than blocking at the TCP layer: the connection attempt never starts, no packets are sent, and the failure is immediate and unambiguous. Some tools (like npm) interpret DNS failures differently from connection refused errors, so the NXDOMAIN approach produces cleaner error messages.

# Proxy architecture

MicroVM → TAP interface → Host proxy → Internet
                            ↓
                     Allowlist check
                     Traffic logging
                     Rate limiting

# DNS resolution flow

MicroVM resolves domain → Host resolver checks allowlist
  ✓ Allowlisted:  Return real IP → connection proceeds
  ✗ Not listed:   Return NXDOMAIN → connection fails immediately

# Proxy configuration for custom endpoints
network:
  proxy:
    http: "http://proxy.internal:3128"
    https: "http://proxy.internal:3128"
    no_proxy: "localhost,127.0.0.1"
  dns:
    custom_resolvers:
      - "10.0.0.53"     # Internal DNS for corp domains
    allowlist_additions:
      - "api.internal.company.com"
      - "registry.internal.company.com"

1. Map your network dependencies Before submitting cloud tasks, list every domain your build and test process contacts. Use browser dev tools or `tcpdump` locally to discover hidden dependencies.
2. Test with restrictive DNS Configure a local DNS resolver that only resolves the Codex default allowlist. Run your test suite and note which tests fail — each failure is a domain you need to either allowlist or mock.
3. Configure corporate proxy If your organization uses a forward proxy, configure it in the Codex network settings. The microVM proxy chains through your corporate proxy for allowed domains.