Network Configuration

This page covers outbound traffic: where your container’s connections exit to the internet. You route them through a SOCKS5, HTTP, or HTTPS proxy, or block them entirely. The route is applied on the host, so nothing inside the container is configured.

API endpoints summary

Complete endpoint documentation:

GET /api/v1/containers/{id}/network - Get current network config
PATCH /api/v1/containers/{id}/network - Configure proxy/VPN/block mode
DELETE /api/v1/containers/{id}/network - Remove config (restore default)
POST /api/v1/containers/{id}/network/start - Start container network proxy/blocking
POST /api/v1/containers/{id}/network/stop - Stop container network proxy/blocking

Two different proxies on Hoody

Hoody uses the word proxy for two systems that work in opposite directions:

System	Direction	Purpose
Hoody Proxy	Internet → Container	Makes services accessible via URLs
Network Configuration (this page)	Container → Internet	Changes exit IP address

Hoody Proxy is how other people reach your containers, inbound. Network Configuration is how your container reaches the internet, outbound. The two run alongside each other: the proxy handles inbound service requests, network configuration handles outbound connections.

Four routing types

A successful update saves the configuration and puts it in force immediately. network stop disables the configured route or block policy without deleting it; network start re-enables a stopped policy.

SOCKS5 proxy (recommended)

Routes all TCP traffic through the SOCKS5 upstream:

# Route all container traffic through SOCKS5 proxy
hoody network update --container $CONTAINER_ID \
  --type socks5 \
  --proxy "socks5://username:password@proxy.example.com:1080" \
  --dns-servers "1.1.1.1,1.0.0.1"

await client.api.containers.updateNetworkConfig(CONTAINER_ID, {
  type: 'socks5',
  proxy: 'socks5://username:password@proxy.example.com:1080',
  dns_servers: ['1.1.1.1', '1.0.0.1'],
});

curl -X PATCH "https://api.hoody.com/api/v1/containers/$CONTAINER_ID/network" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "socks5",
    "proxy": "socks5://username:password@proxy.example.com:1080",
    "dns_servers": ["1.1.1.1", "1.0.0.1"]
  }'

One request, one link

cURL runs inside your container and can wrap any HTTP request into a single GET URL. The call stops being something you need a client for and becomes something you can paste into a browser, send in a chat, bookmark, schedule with cron, or drop into a no-code tool.

Nothing is installed on the machine that opens it. The link does carry whatever credentials the call needs, so treat it as you would treat those credentials.

Slashes, colons and braces pass through as they are. The one character you must encode is an & inside a value, which happens when the wrapped URL carries its own query string. Left raw it ends the value early, and the rest is read as cURL's own parameters, so you get a 200 on a request you did not make.

How the wrapping works Chaining calls into one link Turning a link into a shortcut

Applies the SOCKS5 route immediately, replacing any existing network configuration.

https://PROJECT_ID-CONTAINER_ID-curl-1.SERVER.containers.hoody.com/api/v1/curl/request?url=https://api.hoody.com/api/v1/containers/CONTAINER_ID/network&method=PATCH&bearer_token=TOKEN&json={"type":"socks5","proxy":"socks5://username:password@proxy.example.com:1080","dns_servers":["1.1.1.1","1.0.0.1"]}&response=transparent

The link carries a credential and executes with it, so it is as sensitive as the credential itself — and it passes through the cURL service's request log on the way, not just the target's. Share it only where you would share the secret, and prefer a delegated token with minimal permissions and an expiry: see API tokens.

What happens:

All container TCP connections route through the SOCKS5 proxy
The container appears to originate from the proxy’s IP
Authentication is supported (username:password)

Why SOCKS5 is recommended:

It forwards any TCP protocol natively, without CONNECT tunneling
SSH, databases, Git, and custom protocols all work
Many providers, including VPN services, offer SOCKS5 with credentials
Nothing inside the container needs configuring

HTTP proxy

# Route container traffic through HTTP proxy
hoody network update --container $CONTAINER_ID \
  --type http \
  --proxy "http://user:pass@corporate-proxy.com:8080"

await client.api.containers.updateNetworkConfig(CONTAINER_ID, {
  type: 'http',
  proxy: 'http://user:pass@corporate-proxy.com:8080',
});

curl -X PATCH "https://api.hoody.com/api/v1/containers/$CONTAINER_ID/network" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "http",
    "proxy": "http://user:pass@corporate-proxy.com:8080"
  }'

One request, one link

Nothing is installed on the machine that opens it. The link does carry whatever credentials the call needs, so treat it as you would treat those credentials.

How the wrapping works Chaining calls into one link Turning a link into a shortcut

Applies the HTTP proxy route immediately, replacing any existing network configuration.

https://PROJECT_ID-CONTAINER_ID-curl-1.SERVER.containers.hoody.com/api/v1/curl/request?url=https://api.hoody.com/api/v1/containers/CONTAINER_ID/network&method=PATCH&bearer_token=TOKEN&json={"type":"http","proxy":"http://user:pass@corporate-proxy.com:8080"}&response=transparent

Use for: Corporate proxy requirements, environments that mandate an HTTP forward proxy

Note: type: http configures the upstream as an HTTP proxy. Hoody still DNATs all container TCP egress through it, using the proxy’s CONNECT tunneling for non-HTTP destinations, so this is not limited to plain HTTP payloads. SOCKS5 remains the most broadly compatible upstream.

HTTPS proxy

# Route container traffic through HTTPS proxy
hoody network update --container $CONTAINER_ID \
  --type https \
  --proxy "https://user:pass@secure-proxy.com:443"

await client.api.containers.updateNetworkConfig(CONTAINER_ID, {
  type: 'https',
  proxy: 'https://user:pass@secure-proxy.com:443',
});

curl -X PATCH "https://api.hoody.com/api/v1/containers/$CONTAINER_ID/network" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "https",
    "proxy": "https://user:pass@secure-proxy.com:443"
  }'

One request, one link

Nothing is installed on the machine that opens it. The link does carry whatever credentials the call needs, so treat it as you would treat those credentials.

How the wrapping works Chaining calls into one link Turning a link into a shortcut

Applies the HTTPS proxy route immediately, replacing any existing network configuration.

https://PROJECT_ID-CONTAINER_ID-curl-1.SERVER.containers.hoody.com/api/v1/curl/request?url=https://api.hoody.com/api/v1/containers/CONTAINER_ID/network&method=PATCH&bearer_token=TOKEN&json={"type":"https","proxy":"https://user:pass@secure-proxy.com:443"}&response=transparent

Use for: Encrypted HTTP proxy connections

Note: type: https configures the upstream as an HTTPS proxy (CONNECT tunneling); all TCP egress is DNATed through it just as with the http type, so this is not restricted to HTTPS payloads.

Block (no outbound traffic)

# Block all outbound internet traffic
hoody network update --container $CONTAINER_ID --type block

await client.api.containers.updateNetworkConfig(CONTAINER_ID, {
  type: 'block',
});

curl -X PATCH "https://api.hoody.com/api/v1/containers/$CONTAINER_ID/network" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"type": "block"}'

One request, one link

Nothing is installed on the machine that opens it. The link does carry whatever credentials the call needs, so treat it as you would treat those credentials.

How the wrapping works Chaining calls into one link Turning a link into a shortcut

Switches off all outbound internet for the container immediately. Route it through a different container’s curl-1 — this link cuts the target container’s egress, so it cannot be served by the container it blocks.

https://PROJECT_ID-OTHER_CONTAINER_ID-curl-1.SERVER.containers.hoody.com/api/v1/curl/request?url=https://api.hoody.com/api/v1/containers/CONTAINER_ID/network&method=PATCH&bearer_token=TOKEN&json={"type":"block"}&response=transparent

Block mode blocks all outbound internet. The container can still:

Be accessed via Hoody Proxy URLs (terminal, files, display)
Access localhost services and /ramdisk

It cannot make any outbound internet connections.

Use block mode for a workload that has no business talking to the internet. Updating to block mode switches outbound access off; network stop switches it back on.

Host-level routing

Without it, each application carries its own proxy setting:

export HTTP_PROXY=http://proxy:8080
npm config set proxy http://proxy:8080
git config http.proxy http://proxy:8080
# Every single application needs its own setting

On Hoody, one update call covers every application in the container:

# Configure SOCKS5 proxy for all container traffic
hoody network update --container $CONTAINER_ID \
  --type socks5 \
  --proxy "socks5://user:pass@proxy.example.com:1080"

await client.api.containers.updateNetworkConfig(CONTAINER_ID, {
  type: 'socks5',
  proxy: 'socks5://user:pass@proxy.example.com:1080',
});

curl -X PATCH "https://api.hoody.com/api/v1/containers/$CONTAINER_ID/network" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "socks5",
    "proxy": "socks5://user:pass@proxy.example.com:1080"
  }'

One request, one link

Nothing is installed on the machine that opens it. The link does carry whatever credentials the call needs, so treat it as you would treat those credentials.

How the wrapping works Chaining calls into one link Turning a link into a shortcut

One call routes every application in the container through the SOCKS5 proxy, with nothing configured inside.

https://PROJECT_ID-CONTAINER_ID-curl-1.SERVER.containers.hoody.com/api/v1/curl/request?url=https://api.hoody.com/api/v1/containers/CONTAINER_ID/network&method=PATCH&bearer_token=TOKEN&json={"type":"socks5","proxy":"socks5://user:pass@proxy.example.com:1080"}&response=transparent

Every application then routes through SOCKS5: npm downloads, curl requests, Python/Node.js/Go apps, SSH connections, and database connections. None of them carry a proxy setting.

What that gives you:

Universal routing, covering every TCP protocol
No application-level configuration
Tamper-proof routing, since the container cannot bypass it
Easy VPN provider switching

Use cases

Change the exit IP for a geo-restricted API

Your server is in Germany, but the API requires a US IP:

# Route through US proxy for geo-restricted APIs
hoody network update --container $CONTAINER_ID \
  --type socks5 \
  --proxy "socks5://user:pass@us-proxy.example.com:1080"

await client.api.containers.updateNetworkConfig(CONTAINER_ID, {
  type: 'socks5',
  proxy: 'socks5://user:pass@us-proxy.example.com:1080',
});

curl -X PATCH "https://api.hoody.com/api/v1/containers/$CONTAINER_ID/network" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "socks5",
    "proxy": "socks5://user:pass@us-proxy.example.com:1080"
  }'

One request, one link

Nothing is installed on the machine that opens it. The link does carry whatever credentials the call needs, so treat it as you would treat those credentials.

How the wrapping works Chaining calls into one link Turning a link into a shortcut

Switches the container’s exit IP to the US proxy’s location.

https://PROJECT_ID-CONTAINER_ID-curl-1.SERVER.containers.hoody.com/api/v1/curl/request?url=https://api.hoody.com/api/v1/containers/CONTAINER_ID/network&method=PATCH&bearer_token=TOKEN&json={"type":"socks5","proxy":"socks5://user:pass@us-proxy.example.com:1080"}&response=transparent

Requests from the container now appear to originate from the proxy’s location.

Route through a corporate proxy

# Route through corporate HTTP proxy for compliance
hoody network update --container $CONTAINER_ID \
  --type http \
  --proxy "http://employee:pass@corporate-proxy.com:8080"

await client.api.containers.updateNetworkConfig(CONTAINER_ID, {
  type: 'http',
  proxy: 'http://employee:pass@corporate-proxy.com:8080',
});

curl -X PATCH "https://api.hoody.com/api/v1/containers/$CONTAINER_ID/network" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "http",
    "proxy": "http://employee:pass@corporate-proxy.com:8080"
  }'

One request, one link

Nothing is installed on the machine that opens it. The link does carry whatever credentials the call needs, so treat it as you would treat those credentials.

How the wrapping works Chaining calls into one link Turning a link into a shortcut

Routes container traffic through the corporate HTTP proxy for compliance logging.

https://PROJECT_ID-CONTAINER_ID-curl-1.SERVER.containers.hoody.com/api/v1/curl/request?url=https://api.hoody.com/api/v1/containers/CONTAINER_ID/network&method=PATCH&bearer_token=TOKEN&json={"type":"http","proxy":"http://employee:pass@corporate-proxy.com:8080"}&response=transparent

All HTTP traffic is logged by the corporate proxy for compliance.

Keep an AI workload fully offline

# Block all outbound traffic for AI sandbox
hoody network update --container $CONTAINER_ID --type block

await client.api.containers.updateNetworkConfig(CONTAINER_ID, {
  type: 'block',
});

curl -X PATCH "https://api.hoody.com/api/v1/containers/$CONTAINER_ID/network" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"type": "block"}'

One request, one link

Nothing is installed on the machine that opens it. The link does carry whatever credentials the call needs, so treat it as you would treat those credentials.

How the wrapping works Chaining calls into one link Turning a link into a shortcut

Blocks all outbound traffic so a compromised AI workload cannot call out or exfiltrate data. Route it through a different container’s curl-1 — this link cuts the target container’s egress, so it cannot be served by the container it blocks.

https://PROJECT_ID-OTHER_CONTAINER_ID-curl-1.SERVER.containers.hoody.com/api/v1/curl/request?url=https://api.hoody.com/api/v1/containers/CONTAINER_ID/network&method=PATCH&bearer_token=TOKEN&json={"type":"block"}&response=transparent

In block mode, AI-generated code cannot:

Call external APIs
Download malicious packages
Exfiltrate data

Even if the code is compromised, it stays isolated.

Test from several regions at once

Spawn containers with different exit IPs and run the same request from each:

PATCH Configure US region proxy

/api/v1/containers/{container_id}/network

Click "Run" to execute the request

PATCH Configure EU region proxy

/api/v1/containers/{container_id}/network

Click "Run" to execute the request

PATCH Configure Asia region proxy

/api/v1/containers/{container_id}/network

Click "Run" to execute the request

Layering network, firewall, and permissions

Three layers control traffic, and they stack.

Step 1: Route through the VPN:

PATCH Route all traffic through VPN

/api/v1/containers/{container_id}/network

Click "Run" to execute the request

A successful PATCH saves and activates the VPN route.

Step 2: Allow only HTTPS through the firewall:

POST Allow HTTPS traffic (port 443)

/api/v1/containers/{container_id}/firewall/egress

Click "Run" to execute the request

POST Block all other TCP traffic

/api/v1/containers/{container_id}/firewall/egress

Click "Run" to execute the request

Result: traffic routes through the VPN, and the firewall permits only HTTPS.

The three layers:

Layer	Controls	Page
Network Config	Exit IP routing (outbound)	This page
Firewall	Packet filtering (ingress/egress)	Firewall →
Proxy Permissions	HTTP service access (inbound)	Permissions →

Use all three together to control exit routing, packet filtering, and HTTP service access.

Manage an existing configuration

Get the current config

# View current network configuration
hoody network get --container $CONTAINER_ID

const config = await client.api.containers.getNetworkConfig(CONTAINER_ID);
console.log(config.data); // { type, proxy, dns_servers, status, remote_status }

curl "https://api.hoody.com/api/v1/containers/$CONTAINER_ID/network" \
  -H "Authorization: Bearer $TOKEN"

One request, one link

Nothing is installed on the machine that opens it. The link does carry whatever credentials the call needs, so treat it as you would treat those credentials.

How the wrapping works Chaining calls into one link Turning a link into a shortcut

Returns the container’s current network configuration.

https://PROJECT_ID-OTHER_CONTAINER_ID-curl-1.SERVER.containers.hoody.com/api/v1/curl/request?url=https://api.hoody.com/api/v1/containers/CONTAINER_ID/network&method=GET&bearer_token=TOKEN&response=transparent

Remove the config and restore the default

# Remove network config, restore direct connection
hoody network delete --container $CONTAINER_ID --yes

await client.api.containers.removeNetworkConfig(CONTAINER_ID);

curl -X DELETE "https://api.hoody.com/api/v1/containers/$CONTAINER_ID/network" \
  -H "Authorization: Bearer $TOKEN"

One request, one link

Nothing is installed on the machine that opens it. The link does carry whatever credentials the call needs, so treat it as you would treat those credentials.

How the wrapping works Chaining calls into one link Turning a link into a shortcut

Removes the network configuration and restores the container’s direct connection. Route it through a different container’s curl-1 — if the current config is what’s broken, the target’s own egress can’t serve this link either.

https://PROJECT_ID-OTHER_CONTAINER_ID-curl-1.SERVER.containers.hoody.com/api/v1/curl/request?url=https://api.hoody.com/api/v1/containers/CONTAINER_ID/network&method=DELETE&bearer_token=TOKEN&response=transparent

Start or stop the network proxy

# Start network proxy/blocking
hoody network start --container $CONTAINER_ID

# Stop network proxy/blocking
hoody network stop --container $CONTAINER_ID --yes

// Start network proxy/blocking
await client.api.containers.startNetwork(CONTAINER_ID);

// Stop network proxy/blocking
await client.api.containers.stopNetwork(CONTAINER_ID);

# Start network proxy/blocking
curl -X POST "https://api.hoody.com/api/v1/containers/$CONTAINER_ID/network/start" \
  -H "Authorization: Bearer $TOKEN"

# Stop network proxy/blocking
curl -X POST "https://api.hoody.com/api/v1/containers/$CONTAINER_ID/network/stop" \
  -H "Authorization: Bearer $TOKEN"

One request, one link

Nothing is installed on the machine that opens it. The link does carry whatever credentials the call needs, so treat it as you would treat those credentials.

How the wrapping works Chaining calls into one link Turning a link into a shortcut

Starts or stops the configured route or block policy without deleting it. Route them through a different container’s curl-1 — stopping a block or a dead proxy is exactly when the target’s own egress can’t serve the link.

# Start
https://PROJECT_ID-OTHER_CONTAINER_ID-curl-1.SERVER.containers.hoody.com/api/v1/curl/request?url=https://api.hoody.com/api/v1/containers/CONTAINER_ID/network/start&method=POST&bearer_token=TOKEN&response=transparent

# Stop
https://PROJECT_ID-OTHER_CONTAINER_ID-curl-1.SERVER.containers.hoody.com/api/v1/curl/request?url=https://api.hoody.com/api/v1/containers/CONTAINER_ID/network/stop&method=POST&bearer_token=TOKEN&response=transparent

Verify the exit IP

From inside the container:

# Via hoody-terminal
curl ifconfig.me

# Should show VPN IP, not server IP

Best practices

Use SOCKS5 for universal routing

Hoody DNATs all container TCP egress regardless of proxy type, but a SOCKS5 upstream natively forwards any TCP protocol (SSH, databases, custom protocols) without relying on CONNECT tunneling. Use SOCKS5 unless your environment specifically requires an HTTP/HTTPS forward proxy.

Test the config before production

Test in a dev container first:

PATCH Test proxy configuration in dev container

/api/v1/containers/{container_id}/network

Click "Run" to execute the request

Verify exit IP with curl ifconfig.me from inside the container, test app connectivity, then apply to production.

Write a descriptive route comment

# Good comment
{"comment": "UK VPN for BBC API - geo-restricted content"}

# Vague comment
{"comment": "vpn"}

Combine routing with firewall rules

Route through the VPN, then restrict the allowed destinations with firewall rules.

Useful questions

Does Network Configuration affect container service URLs?

No. Hoody Proxy service URLs (terminal, files, display) remain accessible. Network Configuration only affects outbound connections from the container.

What happens if the SOCKS5 proxy goes down?

The container cannot make outbound connections. Update the config with a different proxy, or call DELETE /network to revert to a direct connection.

Can I use multiple proxies simultaneously?

Network Configuration takes one proxy per container. For multi-hop, configure the first SOCKS5 through Network Configuration and run a second SOCKS5 client inside the container. You can also spawn multiple containers, each with a different proxy.

Does this work with WireGuard or OpenVPN?

Not yet. Network Configuration currently supports SOCKS5, HTTP, and HTTPS proxy routing only. WireGuard routing is planned for a future update. Many VPN providers offer SOCKS5 endpoints as an alternative.

For a real WireGuard tunnel, run the client inside the container instead. That path is yours to configure, and it comes with rules of its own. See VPN Inside a Container →.

Do changes require a container restart?

No. Changes apply immediately to new connections. Existing connections may continue using the old route.

Can containers communicate with each other in `block` mode?

No. Block mode blackholes all new outbound TCP from the container, including connections to other containers’ service URLs, which resolve to public addresses. The blocked container itself stays reachable from outside via its own service URLs; it just can’t dial out. If two containers need to talk while one is blocked, have the unblocked one initiate the connection.

Troubleshooting

No internet access after configuring the VPN

Solutions:

Verify the network service is running: GET /containers/{id}/network → check "status": "running"
Test proxy from host: curl --proxy socks5://user:pass@vpn.com:1080 https://ifconfig.me
Check proxy URL format: socks5://username:password@host:port
Remove config and test direct: DELETE /containers/{id}/network

DNS resolution fails

Solutions:

Configure custom DNS:

PATCH Configure SOCKS5 with custom DNS servers

/api/v1/containers/{container_id}/network

Click "Run" to execute the request

Ensure the firewall allows DNS:

POST Allow DNS traffic (UDP port 53)

/api/v1/containers/{container_id}/firewall/egress

Click "Run" to execute the request

Proxy authentication fails

Check:

The credentials are correct
Special characters are URL-encoded (@ = %40, : = %3A)
The VPN subscription is active
Test from the host: curl --proxy socks5://user:pass@vpn.com:1080 https://ifconfig.me

Exit IP not changing

Verify:

The network service is running: GET /network → check remote_status.is_running is true (or status is running)
Test from container: curl ifconfig.me (should show proxy IP, not server IP)
Check DNS leaks: curl -4 ifconfig.me (force IPv4)

What’s next

Complete networking setup:

Firewall → - Granular traffic rules
VPN Inside a Container → - Run a WireGuard tunnel inside the container
SSH Access → - Secure shell and SFTP
IPv4 Management → - Dedicated IPs (coming soon)

What this page covered:

Network Configuration controls outbound traffic and the exit IP
Hoody Proxy controls inbound traffic and service URLs
SOCKS5 routes any TCP protocol, which makes it the most versatile upstream
Routing is applied on the host, so containers need no configuration
Block mode leaves no outbound internet path

Network Configuration

API endpoints summary

Two different proxies on Hoody

Four routing types

SOCKS5 proxy (recommended)

HTTP proxy

HTTPS proxy

Block (no outbound traffic)

Host-level routing

Use cases

Change the exit IP for a geo-restricted API

Route through a corporate proxy

Keep an AI workload fully offline

Test from several regions at once

Layering network, firewall, and permissions

Manage an existing configuration

Get the current config

Remove the config and restore the default

Start or stop the network proxy

Verify the exit IP

Best practices

Use SOCKS5 for universal routing

Test the config before production

Write a descriptive route comment

Combine routing with firewall rules

Useful questions

Does Network Configuration affect container service URLs?

What happens if the SOCKS5 proxy goes down?

Can I use multiple proxies simultaneously?

Does this work with WireGuard or OpenVPN?

Do changes require a container restart?

Can containers communicate with each other in block mode?

Troubleshooting

No internet access after configuring the VPN

DNS resolution fails

Proxy authentication fails

Exit IP not changing

What’s next

Can containers communicate with each other in `block` mode?