Browser profile proxy setup: one proxy, WebRTC and DNS

Originally published on proxymint.

Set up one proxy per browser profile: own credentials per profile, the proxy type for each job, and how to check WebRTC, DNS and language before login.

TL;DR

• A browser profile proxy setup gives each profile its own proxy. The profile keeps its own cookies, saved logins and settings such as language; the proxy decides where its traffic leaves from: IP, network, country and city.
• One profile, one proxy, one set of credentials. Each client's sessions stay on one consistent address, and no profile carries another client's proxy login.
• Pick the tier by the job. ISP for long-lived logins, residential with a sticky timer for logged-out ad checks, mobile for app-first accounts, datacenter IPv4 for QA on your own sites.
• WebRTC and DNS are the usual leaks. RFC 8828 notes that HTTP and most SOCKS proxies carry no UDP, so set WebRTC to proxy-only, and confirm that names resolve on the proxy side.
• Verify inside the launched profile before the first login. Check exit IP, language, WebRTC, DNS resolver and IPv6, and run it again after any exit change.

Key takeaways

• Assign exactly one proxy to each profile. Name the profile after the client or market, paste host, port, username and password, and use the http:// scheme.
• Keep credentials per profile. A static ISP IP comes with its own username and password; on per-GB tiers give each profile its own port and each client its own order.
• Set the language for the market. The profile language drives navigator.language and Accept-Language; set it to the market whose pages the job needs.
• Switch WebRTC to proxy-only or address replacement. Never leave the default that routes WebRTC from the host network.
• Use the platform's own access route first. Meta partner access and Google Ads manager accounts often remove the need for a separate profile holding a client's login.

Read the full guide on proxymint, with the commands, tables and sources.