Repository navigation
Make Chrome and proxyrouter DNS configurable together - #44
Merged
mandatoryprogrammer merged 4 commits intoOct 5, 2026
Merged
Conversation
The chrome service already sets an explicit DNS resolver (8.8.8.8/1.1.1.1) to work around Docker setups where the embedded resolver isn't reliably reachable (e.g. rootless Docker with a VM-based network stack). proxyrouter never got the same override, even though it's the service that actually resolves every proxied request's target host. Without working DNS in proxyrouter, requests fail (intermittently or entirely depending on the environment) with generic connection errors that give no indication DNS is the cause.
mandatoryprogrammer
changed the title
Owner
|
Added support for this (there were some caveats to the existing PR), thanks for the contribution! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
DNS failures in proxyrouter can prevent requests even when Chrome has working DNS. Add one optional
THERMOPTIC_DNSCompose variable so operators can select the same resolver for both services without editing separate settings.THERMOPTIC_DNSto one literal IPv4 or IPv6 resolver address in the shell or Compose.envfile._readme/internal-notes.md.Validation used Docker Engine 29.7.2, Compose 5.5.0, and existing Chrome/router images. Fifteen configuration checks passed for unset/empty values, IPv4/IPv6, CI/GPU overlays, and environment-file precedence. Actual container checks confirmed identical DNS settings, automatic recreation when changing or clearing the variable, and working Docker service discovery. With a private local DNS fixture, the Chrome container's OS resolver resolved the target and the actual router returned HTTP 200. These initial checks used the Chrome container's OS resolver; the separate run below also exercised the actual browser. No builds, image pulls, or dependency installs were needed for local validation.
Full-stack verification on 2026-10-05 used the current PR source with the existing Chrome 142.0.7444.175 image and a private DNS/HTTP fixture. Six authenticated requests from the host through the published loopback proxy port passed: navigation and
fetch()with direct router egress, a privately named upstream HTTP proxy, and Chrome bypassing the router for the private target. All returned HTTP 200 with the exact 72-byte UTF-8 body and correct Content-Length. Application routing logs and fixture DNS/origin logs confirmed the browser paths and that both Chrome and proxyrouter used the selected resolver. Temporary profiles, CA material, containers, and the network were isolated from the regular deployment. No dependency installs, image pulls, or rebuilds were needed.The test network used a non-overlapping subnet because this host's Tailscale route captures Docker's automatically allocated subnet. This run covered HTTP over IPv4; live IPv6 DNS and the reporter's rootless/VM environment remain untested. The latest PR head also passes the existing
compose-e2eanddocker-buildCI jobs.