Proxy per Browser Profile: DNS, Authentication, and Failure Modes

This guide uses Chromium’s documented network behavior as the reference point. Other browsers and products can make different choices, and a browser manager can add a local network broker around Chromium. Verify the behavior of the exact build you operate.

Start with four independent questions

A proxy record usually contains a scheme, endpoint, port, and sometimes an authentication reference. That record leaves four separate policy questions:

1. Coverage: Which browser requests and protocols are assigned to this proxy?
2. Name resolution: Does the device or the proxy resolve the destination hostname?
3. Authentication: Which client and proxy schemes work together, and where are credentials stored?
4. Failure: Does a connection error stop the request, try another proxy, or fall back to a direct route?

Treating these as one “proxy on” switch causes most surprises. Chromium documents proxy selection as URL-level resolution: a URL produces an ordered list of proxy choices before the destination is necessarily resolved. Bypass and fallback rules are part of that decision.

What a per-profile proxy covers

Google’s ProxySettings policy is applied at Chrome profile level. It can select direct, system, auto-detected, fixed-server, or PAC-script modes, with explicit bypass and PAC-mandatory fields.

That boundary is narrower than a VPN or operating-system network namespace. It governs requests handled by the browser network context. It does not automatically govern:

• the desktop manager’s own API calls;
• an out-of-process application or browser updater;
• operating-system DNS and connectivity checks;
• another application launched from a downloaded file;
• an extension’s separate native helper;
• local services reached through implicit loopback bypasses; or
• traffic using a protocol that the selected proxy path cannot carry.

Some of those components may have their own proxy support. That support must be specified and tested separately. A browser-product statement such as “profile traffic uses this proxy” should identify the included processes and protocols rather than imply device-wide routing.

Follow one HTTPS request

For a normal HTTPS navigation, the path has several steps.

1. Choose the route

The browser evaluates fixed rules, a proxy auto-configuration script, or system settings. A bypass match can select a direct connection. A proxy list can select a primary proxy followed by alternatives, including DIRECT if direct fallback is allowed.

Chromium also applies implicit bypasses for localhost and link-local destinations. This protects local origins from externally controlled proxy settings, but it means a broad “all traffic” description needs qualification.

2. Resolve and reach the proxy

If the proxy endpoint is a hostname, the device still needs a way to resolve and connect to that endpoint. Remote destination DNS does not eliminate this bootstrap lookup. A failure here differs from the proxy being reachable but unable to resolve the destination.

3. Authenticate to the proxy

An HTTP proxy that requires credentials normally returns 407 Proxy Authentication Required with a challenge. RFC 9110 defines that exchange and the Proxy-Authenticate and Proxy-Authorization fields.

Chromium does not use a username and password embedded in manual proxy settings. Its proxy documentation says authentication follows the browser’s ordinary credential flow instead. A profile manager therefore needs an explicit integration for the supported challenge, not a promise that any user:password@host string will work.

4. Establish the destination connection

With an HTTP proxy, Chromium defers destination name resolution to the proxy. For an HTTPS destination, the browser asks the proxy to create a CONNECT tunnel and then performs end-to-end TLS with the destination through that tunnel.

The proxy still learns the destination hostname and connection metadata. When the client-to-proxy hop uses plain HTTP, the CONNECT request and its hostname are not protected on that hop. An HTTPS proxy adds TLS between browser and proxy, protecting that metadata from observers between them. It does not make the proxy itself unable to see the requested destination.

The proxy cannot normally read the HTTPS page content carried inside the tunnel. TLS interception is a different trust model in which a client trusts a certificate authority that allows the intermediary to terminate and recreate TLS. That should never be silently conflated with ordinary forwarding.

DNS ownership changes with the proxy scheme

Chromium’s documented behavior differs by proxy type:

Selected route	Destination name resolution in Chromium	Important limit
Direct or bypass	Device or browser resolver	Destination traffic leaves without the profile proxy
HTTP proxy	Proxy side	Plain HTTP client-to-proxy transport exposes HTTP requests; HTTPS uses CONNECT
HTTPS proxy	Proxy side	Client must validate the proxy’s TLS certificate
SOCKS4 proxy	Client side	IPv4 destination only; Chromium does not implement SOCKS4a fallback
SOCKS5 proxy	Proxy side	Chromium uses it for TCP URL requests and documents no SOCKS5 authentication support

RFC 1928 allows a SOCKS5 request to carry a domain name and defines several authentication-method identifiers. Protocol capability does not guarantee client implementation. Chromium currently sends destination names to a SOCKS5 proxy but states that its built-in SOCKS5 client supports no proxy authentication methods. A provider offering username-and-password SOCKS5 access may therefore require a supported intermediary or a different proxy scheme. Confirm the browser’s implementation before accepting the record.

DNS-over-HTTPS adds another layer. Chrome’s DnsOverHttpsMode policy distinguishes automatic, which may fall back to insecure DNS, from secure, which fails resolution when secure DNS fails. The same policy is documented as browser-level, while ProxySettings is profile-level. That mismatch is a useful warning: the word “profile” on one setting does not imply that every DNS control has the same scope.

A product that runs each profile in a separate browser process can create a narrower effective boundary, but that is an implementation choice. Test it. The evidence should distinguish:

• resolution of the proxy endpoint;
• resolution of the requested destination;
• DNS used by direct or bypassed requests;
• secure-DNS bootstrap and fallback; and
• DNS performed by components outside the profile’s browser network context.

Authentication is both a compatibility and secret-handling problem

Chromium documents Basic, Digest, Negotiate, and NTLM for HTTP proxies. HTTPS proxies add a protected client-to-proxy channel and can also support client certificates. SOCKS4 and SOCKS5 authentication are not implemented by Chromium’s built-in proxy client, despite authentication methods existing in the SOCKS5 specification.

Even a compatible scheme can be unsafe in the wrong transport. RFC 7617 explains that Basic credentials are only Base64-encoded and require a protected channel such as TLS. Using Basic authentication to a plain HTTP proxy exposes the proxy password to anyone able to observe that hop.

A profile manager should keep the following data separate:

• non-secret endpoint metadata, such as scheme, host, port, and provider label;
• a secret reference used by the lifecycle or network service;
• the credential value in protected storage;
• redacted connection state for the interface and audit trail; and
• diagnostic detail that is available only through a controlled support flow.

Normal screens, logs, APIs, exports, and automation output do not need the proxy password. An operator usually needs to know that authentication failed, which scheme was challenged, which endpoint was involved, and whether any fallback occurred.

Failure modes and what they look like

Failure	Likely symptom	Boundary to verify
Wrong proxy scheme	TLS or protocol handshake fails	Was an HTTPS endpoint declared as HTTP, or the reverse?
Proxy hostname cannot resolve	Connection fails before the proxy is reached	Which resolver performed the bootstrap lookup?
Proxy port is unreachable	Timeout or connection refusal	Is another proxy or DIRECT next in the list?
Authentication challenge is unsupported	Repeated 407 or sign-in prompt	Does the browser implement the challenged scheme?
Credential is wrong or expired	407 after credential submission	Was the secret reference resolved, and was it redacted from output?
HTTPS proxy certificate fails	Secure connection to proxy is rejected	Is certificate validation intact?
Proxy cannot resolve destination	Proxy-specific host or tunnel failure	Did the client avoid retrying the destination directly?
CONNECT is denied	HTTPS navigation fails for that destination	Is denial treated as policy, not as permission to bypass?
PAC file is unavailable	Proxy resolution stalls or changes route	Is the PAC mandatory, or can Chromium silently use DIRECT?
Bypass pattern is too broad	Selected sites connect directly	Are exact host, subdomain, port, and implicit rules understood?
WebRTC uses another interface	Media path differs from page traffic	Is non-proxied UDP disabled for the profile?
Existing connection survives a change	Old route remains temporarily active	Are connections drained or the profile restarted?
Diagnostic capture is over-detailed	URLs, hostnames, or secrets enter a support file	Which redaction mode and retention rule apply?

Chromium’s fallback is stateful. A proxy with a connection-level failure can be marked as bad and moved behind other entries for a period. If DIRECT is in the list, later requests can leave without the proxy. A CONNECT rejection is handled differently because it may represent an intentional destination policy rather than an unavailable proxy.

PAC failure needs particular attention. Chromium documents that an unavailable PAC file can silently fall back to direct resolution unless the PAC is marked mandatory. Chrome’s ProxySettings policy exposes ProxyPacMandatory specifically to prevent that direct fallback.

WebRTC and UDP need their own decision

A page can use WebRTC paths that are not equivalent to ordinary HTTP and HTTPS URL requests. Chrome’s default WebRtcIPHandling policy can use all available interfaces. Its disable_non_proxied_udp mode restricts WebRTC to TCP on the public interface unless a configured proxy supports UDP.

That policy is documented as profile-level, which makes it relevant to a profile proxy, but it remains a separate control. It may reduce media performance or break a workflow that requires direct UDP. Choose and test the trade-off explicitly. Do not claim full proxy containment based only on a successful page-load check.

Decide whether failure is closed or available

Direct fallback can be legitimate for a general browsing profile that values availability. It is unsafe for a workflow whose authorization, privacy, or regional test validity depends on a specific egress path.

A good profile policy names the intended behavior:

• Required proxy: stop affected network requests when the selected path cannot be used.
• Approved proxy set: try only named alternatives with equivalent policy.
• Direct fallback allowed: show that the route changed and record the event without secret values.
• Explicit bypass: document the destination class and why direct access is required.

The interface should make route state visible before launch and after a failure. Quietly changing from proxy to direct turns a network error into an integrity error: the workflow may appear to succeed while using the wrong path.

A safe validation matrix

Test with endpoints and DNS zones that you own or are authorized to inspect. Record expected results before running the test.

1. Verify the declared proxy scheme against the actual endpoint transport.
2. Confirm successful HTTP, HTTPS, WebSocket, and required WebRTC behavior.
3. Observe the egress address at a controlled destination.
4. Observe which resolver receives the destination lookup and which resolver bootstraps the proxy hostname.
5. Expire a test credential and confirm that no raw value appears in the interface, logs, or automation output.
6. Make the test proxy unreachable and confirm the configured fail-closed or fallback result.
7. Deny one controlled CONNECT destination and confirm that policy denial does not become direct access.
8. Make a test PAC unavailable and confirm mandatory behavior.
9. Exercise exact, subdomain, local, link-local, IPv4, and IPv6 bypass cases that the workflow needs.
10. Change the proxy while connections are active and verify when the new route takes effect.
11. Capture only the diagnostic detail needed for the test, then verify retention and deletion.

Chromium’s NetLog guidance treats network logging as a privacy and security concern. Redacted modes can omit sensitive fields, while more detailed modes may include cookies or authentication headers. A support file should be handled according to its actual capture mode, not its filename.