FAQ
Common questions about Mullgate's setup flow, routing model, platform support, and troubleshooting.
What is Mullgate?
Mullgate is a CLI-first proxy and gateway product. It exposes local proxy entrypoints, keeps route selection explicit, and provides status and diagnostic surfaces so operators can verify what is happening.
Is Mullgate a VPN client?
Not in the usual full-device sense. Mullgate's documented goal is standalone proxy behavior without taking over host routing.
How do I choose a route?
Use the saved access mode:
- in
published-routes, use the route's configured hostname or its direct host-and-port entrypoint - in
inline-selector, use one shared listener and put the selector in the username, for examplesocks5://ca:@100.124.44.113:1080
In private-network + published-routes, multiple routes can share one host IP because the ports differ.
Why are bind IPs so important?
They still define the published host story, but the runtime is split by exposure and access mode. private-network + published-routes uses one shared trusted-network host IP and route-specific ports. public + published-routes still relies on distinct bind IPs. inline-selector uses one shared host because the username selector chooses the route.
Should I use 0.0.0.0 for Tailscale or other private-network access?
No. 0.0.0.0 is a bind-any address, not the client target other machines should dial. In private-network, use the host's actual trusted-network address, such as its Tailscale 100.x IP.
Can I put the country, city, or exact server into the proxy username?
Yes, if you switch to inline-selector. The guaranteed form is scheme://selector:@host:port.
Examples:
socks5://ca:@100.124.44.113:1080socks5://ca-tor:@100.124.44.113:1080socks5://ca-tor-wg-301:@100.124.44.113:1080
See Inline Selector Reference for the supported selector families and caveats.
If you want a generated file of route URLs instead, stay on published-routes and use mullgate proxy export.
What is the easiest way to test Mullgate locally?
Use a Linux machine and start with a two-route loopback setup. Then run mullgate proxy access, install the emitted hosts block, and probe the published entrypoints with a real client such as curl.
Does Mullgate fully support macOS and Windows runtime behavior?
The CLI, config inspection, and diagnostic surfaces are supported, but the current shipped multi-route Docker runtime is Linux-first. Docker Desktop host networking does not match Linux networking behavior closely enough to treat it as equivalent.
Does each route consume its own Mullvad WireGuard device?
No. The current runtime provisions one shared Mullvad WireGuard entry device and fans out to route-specific Mullvad SOCKS5 exits from inside that tunnel.
Why is there still a multi-exit architecture page?
That page explains the redesign history that closed the original slot-limit problem. It is no longer an aspirational next-step document.
Which pages should I read first?
A good path is:
What if hostname-based routing is not working?
Check the output from:
mullgate proxy accessmullgate proxy accessmullgate proxy doctor
Most hostname issues come down to a missing hosts block, incorrect DNS, or a hostname resolving to the wrong bind IP.
In private-network, "wrong" usually means the hostname does not resolve to the shared host IP that mullgate proxy access reported.
Why does public inline-selector reject my empty password?
That combination exposes one shared public listener and is blocked by default. Either set a non-empty proxy password or opt in explicitly with --unsafe-public-empty-password.