Add WithDialer option for custom TCP dialer injection

[myleshorton]

Summary

• Adds a WithDialer(func(ctx context.Context, network, addr string) (net.Conn, error)) option to fronted
• Threads the custom dialer through loadFronts → newFront → front.dial(), adapting it to tlsdialer.Dialer.DoDial via context.WithTimeout
• Falls back to (&net.Dialer{}).DialContext when no custom dialer is provided (preserving existing behavior)

Test plan

• go build ./... compiles cleanly
• go vet ./... passes
• Existing tests pass (go test ./...)
• Verify domain fronting still works end-to-end with default dialer
• Verify custom dialer is called when injected via WithDialer

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Adds support for injecting a custom TCP dialing function into the fronted client so callers can control how underlying network connections are established (e.g., for custom transports, proxies, or instrumentation), while preserving default behavior when not provided.

Changes:

• Introduces WithDialer(func(ctx context.Context, network, addr string) (net.Conn, error)) option and stores it on fronted.
• Threads the dial function through loadFronts → newFront → front.dial() and adapts it to tlsdialer.Dialer.DoDial using context.WithTimeout.
• Updates TestLoadFronts to match the new loadFronts signature.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
fronted.go	Adds dialFunc to fronted, a WithDialer option, and threads dialer injection through onNewFronts/loadFronts.
front.go	Stores dialer on front and uses it in front.dial() by adapting to tlsdialer.Dialer.DoDial.
fronted_test.go	Updates loadFronts callsite for the new parameter.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

New public option WithDialer adds behavior that isn’t covered by tests yet. Please add a unit test that injects a dialer via WithDialer, triggers a dial (e.g., by calling fr.dial(...) or f.doDial(...) with a dialer that records invocation and returns a sentinel error), and asserts the injected dialer is called and its error is propagated.

[Copilot]

The dialer function type is repeated in several places (fronted.dialFunc, WithDialer, loadFronts, front.dialFunc, newFront). Consider introducing a named type (e.g., type DialFunc func(context.Context, string, string) (net.Conn, error)) to reduce duplication and make future signature changes safer.

Suggested change

	// fronted identifies working IP address/domain pairings for domain fronting and is
	// an implementation of http.RoundTripper for the convenience of callers.
	type fronted struct {
	dialFunc func(ctx context.Context, network, addr string) (net.Conn, error)
	// DialFunc is the function type used for dialing network connections.
	type DialFunc func(ctx context.Context, network, addr string) (net.Conn, error)
	// fronted identifies working IP address/domain pairings for domain fronting and is
	// an implementation of http.RoundTripper for the convenience of callers.
	type fronted struct {
	dialFunc DialFunc

[Copilot]

The WithDialer docstring says it’s for “making TCP connections to fronting domains”, but the dialer is ultimately invoked with the addr passed to tlsdialer.Dialer.Dial("tcp", addr), which (in front.dial) is built from fr.IpAddress (plus default port). Consider clarifying in the comment that the injected dialer will typically receive an IP:port target, while SNI/ServerName is handled separately via TLS config.

Suggested change

	// inject their own dialer for making TCP connections to fronting domains.
	// inject their own dialer for making the underlying TCP connections. The dialer will typically
	// be invoked with an IP:port destination (derived from the configured fronting infrastructure),
	// while the fronting domain name (SNI/ServerName) is configured separately via the TLS settings.