Connections blocked by a firewall or proxy

Share this article with your IT team. The table below lists every host and port MultiClaw needs — allowlisting them is the fastest way to resolve connection issues on managed networks.

The most common symptoms of a blocked connection are: the gateway starts but agents stay disconnected, cloud desktops won't connect, or auto-updates fail silently.

Allowlist

You only need to allowlist the LLM provider APIs for the models you have configured. If you haven't connected a Google Gemini model, for example, you can skip that row.

If UDP is blocked

Some networks block outbound UDP entirely. If cloud desktops won't connect after allowlisting turn.multiclaw.io, go to Settings > Gateway, scroll to the Browser Automation section, and set WebRTC connection mode to TURN relay. This routes all traffic over TCP port 443 instead of UDP.

Configuring a proxy

MultiClaw respects the system HTTP_PROXY and HTTPS_PROXY environment variables automatically. Set these in your shell profile or system environment settings before launching the app.

Deep packet inspection (DPI)

All MultiClaw connections use TLS. If your network uses DPI that intercepts and re-signs TLS traffic, WebSocket and WebRTC connections may break even when the domain is allowlisted. Ask your IT team to exclude *.multiclaw.io and turn.multiclaw.io from DPI inspection.

Still not connecting?

If agents remain disconnected after your IT team has applied the allowlist rules, check https://status.multiclaw.io for active incidents. If there's no incident, review the gateway log at ~/.openclaw/logs/gateway.log for error details.