Multilogin Proxy Setup for Custom Browser Profiles

Multilogin attaches a proxy to a browser profile, so the route, cookies and local storage travel through the profile boundary you selected. The setup is complete only when the product accepts the endpoint and the running profile reaches the expected exit and target content. The profile check is evidence about connection at that moment, not a guarantee about the next page.

This guide is for a purchased third-party endpoint in Multilogin's browser profiles and Quick flow. The anti-detect browser proxy setup hub links to this guide and the other tool-specific procedures. If your workspace uses GoLogin, follow the GoLogin proxy guide.

Map provider fields before opening Multilogin

Collect the endpoint details and decide how you will accept the test:

Multilogin's custom proxy guide documents IP:port:login:password for password-authenticated endpoints and IP:port for endpoints that use IP authentication. Do not paste a username and password into an IP-authenticated record, and do not assume that a provider's URL format is accepted by the Custom form. A SOCKS5 endpoint remains SOCKS5 in the protocol selector.

Multilogin documents custom SOCKS5 support at the product level. Chromium's raw proxy layer supports SOCKSv5 transport but states that SOCKSv5 authentication is not supported by Chrome. An endpoint that requires SOCKS5 username/password therefore needs the Multilogin path or provider integration that explicitly supports that authentication. A generic Chrome proxy setting with embedded credentials is not a valid workaround. For an HTTP or HTTPS endpoint, test the host and port separately with the curl proxy guide before diagnosing the profile.

Configure a regular profile

Use the current Multilogin path Profiles → Browser → create or edit a profile → Proxy. The Proxy section offers four modes:

For a third-party endpoint, select Custom, choose HTTP, HTTPS or SOCKS5, enter the IP or hostname and port, add credentials when required, and save the profile. Multilogin checks the proxy automatically. “Proxy check passed” means Multilogin connected and obtained the required IP-dependent data; “Proxy check failed” means the connection could not be completed. Start the profile and run the browser-level checks below even after a pass.

Templates help with repetition. The current profile settings page says a template can apply saved custom or Multilogin settings to multiple profiles and offers a one-click test. Treat that test as a configuration check for the template. Open one of the actual profiles and verify its live route before using it for a permitted workflow.

Configure Quick profiles and lists

For a one-off profile, open Quick on the main dashboard, choose Custom in Proxy, choose One proxy under Format, select the protocol, and enter IP:port or IP:port:login:password.

For a list, choose Proxy list under Format and add at most 25 proxies in those same formats. The documented selection modes are Sequentially, from top to bottom, and Randomly, in random order without repetition. The selected list and rotation behavior change the meaning of an exit check: record which entry was used, and do not compare a later request with the first entry unless the route is meant to be stable.

Verify the live browser route

Run the test from the same profile or Quick browser that will perform the approved work:

1. Open an IP endpoint you operate or explicitly trust. Record the observed exit and compare it with the provider's expected value or session log.
2. Open the target HTTPS page and record the final URL, response status and a distinctive title, selector or record field.
3. If location matters, keep language, timezone, account state and parser fixed. An IP country is one signal; it does not guarantee a target's currency, locale or content variant.
4. Store expected_country, observed_exit, target_final_url, content_check and timestamp, then close the profile through Multilogin after the test.

The checker and the target answer different questions. A passed proxy check can coexist with a redirect, sign-in page, challenge, 403 or empty application shell. Diagnose the target response separately from the route.

Troubleshoot the first failed phase

Use these tools for accounts and workflows you own or are authorized to operate. A proxy and a browser profile do not grant access to a target or permission to push through its rate limits. Keep retained evidence redacted to profile identifier, phase, target host, status, validator result and timestamp.