Using Multilogin in Restricted Regions: VPN, Agent, and Network Access

Multilogin can work from a restricted region, but the whole connection path has to work. Turning on a VPN or proxy does not automatically connect the dashboard, local launcher, and browser profile. Each can follow a different route or encounter a different permission check.

Our practical case took place in mainland China on October 31, 2026. Adjusting the computer’s network setup and reconnecting the local component allowed us to launch profiles and complete the subsequent tests. Mainland China is the observed example in this article; our broader analysis concerns the connection requirements that users face on restricted networks.

Our assessment is usable with additional setup effort. The product’s profile capabilities became accessible once the connection arrangement worked, but reaching that point demanded an understanding of more than the profile proxy setting.

What happened in our mainland China case

During setup, we encountered dashboard access problems, a disconnected local component, and difficulty opening profile windows. Changing the network arrangement and reconnecting the component restored access. Reversing the proxy arrangement later caused the dashboard to become inaccessible again.

For the subsequent T03 tests, we kept the working configuration fixed: one Mac, Mimic 155.5, Clash with TUN enabled, global routing, and a Hong Kong node. TUN routes traffic through a virtual network interface. Both Multilogin profiles used the option labeled “无全局IP” in the Chinese UI, meaning no separate profile proxy was selected. Their traffic used the computer’s existing network path.

The detailed profile results are in our isolation and fingerprint stability test. Here, the useful question is why one connection arrangement worked while another did not.

What Multilogin officially recommends

Multilogin’s restricted-region help page recommends a VPS outside the restricted location. A VPS is a remote computer on which the software can run. The page addresses mainland China and other locations with national network restrictions. Official restricted-region guidance.

Its Agent troubleshooting page separately explains that the web interface needs permission to communicate with the component on your computer. It includes browser checks for local network or device-app access. The desktop app already contains the Agent. Official Agent connection troubleshooting.

These describe two different concerns: where the software runs and whether its management interface can reach its launcher. Our successful setup ran on the local Mac. The VPS route is the vendor’s documented alternative, with its own remote-computer workflow and operating cost.

Why Google can load while Multilogin stays disconnected

An Agent is the background component that connects the web dashboard to profiles on your computer. The dashboard can load successfully while that local connection fails. Equally, a profile can open but fail to load the website you need.

Google loading in an ordinary browser demonstrates a working route from that browser to Google. The background component can have different routing, and browser permissions can separately block communication with a local service.

Our interpretation: a suitable setup needs both reachable external services and intact local communication. This explains why switching a network tool’s mode can help one part of the workflow while disrupting another. It also gives a more useful starting point than treating every failure as a bad proxy IP.

VPN, system proxy, and profile proxy: what changes?

A system proxy asks compatible applications to send traffic through a proxy. A browser extension may cover an even narrower set of requests. A device-level tunnel can cover more applications, depending on its routing rules. Split tunneling decides which connections take that route.

That is why a direct VPN app may work immediately for one user while another tool needs additional configuration. The decisive question is which connections it carries and how it handles local communication. The label “VPN” alone does not answer either question.

The profile proxy has a separate job: it chooses the route used by that browser profile. It is useful when profiles need their own exit IPs. Setting one does not by itself establish the dashboard’s access to Multilogin or the dashboard’s connection to the launcher.

Our case also exposed a terminology problem. “Global” routing in the computer’s network tool and the Chinese Multilogin label containing “全局IP” describe different controls. English-speaking users should think in terms of computer connectivity and profile proxy configuration. This makes the same underlying distinction easier to follow.

A practical troubleshooting sequence

1. Open the official dashboard and confirm that the workspace loads. This checks the management entry point.
2. Check the local launcher status. If the web interface reports a disconnected Agent, inspect the relevant browser permission and reconnect the component using the official instructions.
3. Launch a dedicated test profile. Confirm that a browser window opens before diagnosing its website traffic.
4. Open the target website inside that profile and check the exit IP. Compare it with the route you intended to use.
5. Record the working settings. Change one network option at a time and note which stage stops working.

If you use the desktop app with the web interface, follow the vendor’s component handoff procedure. The independent legacy Agent and the app’s built-in component need a clear owner for profile launching. See our web and desktop workflow analysis.

This sequence ties each symptom to a specific layer. It is a more productive way to diagnose the problem than repeatedly changing the profile’s fingerprint settings when the dashboard itself cannot connect.

Our verdict on restricted-region usability

Multilogin’s network adaptation is a setup cost users need to budget for. In our mainland China case, the working connection supported profile launching, browsing, isolation testing, and recovery checks. The difficult part was establishing and maintaining the correct combination of external access and local component communication.

Our product recommendation is to make those stages explicit in the interface: service access, launcher access, profile launch, and target-site access. An error should identify the failed stage and offer a relevant next step. A general connection error transfers too much diagnosis to the user.

For users on restricted networks, the buying decision should therefore include the time needed to prepare a working route and recover from connection changes. Profile capabilities retain their value, while the quality of setup guidance determines how readily users can reach them.

More from the Multilogin review series

• Multilogin Review: Profile Isolation, Fingerprint Stability, and Everyday Use
• Using Multilogin in Restricted Regions: VPN, Agent, and Network Access
• Multilogin Web vs. Desktop: How to Choose Cloud or Local Profile Storage
• Multilogin Profile Isolation and Fingerprint Stability: Defaults, Canvas Noise, and Restarts
• Multilogin Data Recovery Test: Saved Logins, Browser State, and Deleted Profiles