server with TLS enabled can not use same host ports for gRPC

Error message

server with TLS enabled can not use same host ports for gRPC and HTTP.  Use dedicated HTTP and gRPC host ports instead

What it means

NewServer refuses to start the jaegerquery extension when TLS is enabled for HTTP and/or gRPC while both protocols are configured on the same host:port. With TLS there is no way to demultiplex gRPC and HTTP on one listener in this setup, so the server fails fast at construction with this configuration error rather than misbehaving at runtime.

Source

Thrown at cmd/jaeger/internal/extension/jaegerquery/internal/server.go:77

	querySvc *querysvc.QueryService,
	metricsQuerySvc metricstore.Reader,
	options *QueryOptions,
	backendCaps BackendCapabilityProvider,
	tm *tenancy.Manager,
	telset telemetry.Settings,
) (*Server, error) {
	_, httpPort, err := net.SplitHostPort(options.HTTP.NetAddr.Endpoint)
	if err != nil {
		return nil, fmt.Errorf("invalid HTTP server host:port: %w", err)
	}
	_, grpcPort, err := net.SplitHostPort(options.GRPC.NetAddr.Endpoint)
	if err != nil {
		return nil, fmt.Errorf("invalid gRPC server host:port: %w", err)
	}
	separatePorts := grpcPort != httpPort || grpcPort == "0" || httpPort == "0"

	if (options.HTTP.TLS.HasValue() || options.GRPC.TLS.HasValue()) && !separatePorts {
		return nil, errors.New("server with TLS enabled can not use same host ports for gRPC and HTTP.  Use dedicated HTTP and gRPC host ports instead")
	}

	grpcServer, err := createGRPCServer(ctx, options, tm, telset)
	if err != nil {
		return nil, err
	}
	registerGRPCHandlers(grpcServer, querySvc, telset)
	httpServer, err := createHTTPServer(ctx, querySvc, metricsQuerySvc, options, backendCaps, tm, telset)
	if err != nil {
		return nil, err
	}

	return &Server{
		queryOptions: options,
		grpcServer:   grpcServer,
		httpServer:   httpServer,
		telset:       telset,
	}, nil

View on GitHub (pinned to 806f444784)

Solutions

Assign distinct host:ports to the HTTP and gRPC servers (e.g. HTTP :16686, gRPC :16685) in the query extension config.
If you intentionally want one port, disable TLS on at least the side that must share (not recommended in production).
A port of "0" is treated as separate (auto-assign); ensure you did not expect TLS port-sharing to work like the non-TLS single-port mode.

Example fix

// before: shared port with TLS
http-server:
  host-port: ":16686"
  tls: {enabled: true}
grpc-server:
  host-port: ":16686"  # same port -> error
// after
http-server:
  host-port: ":16686"
  tls: {enabled: true}
grpc-server:
  host-port: ":16685"
  tls: {enabled: true}

Defensive patterns

Strategy: validation

Validate before calling

func validatePorts(httpHP, grpcHP string, httpTLS, grpcTLS bool) error {
    hp, _ := net.SplitHostPort(httpHP)
    gp, _ := net.SplitHostPort(grpcHP)
    same := hp == gp && hp != "0"
    if (httpTLS || grpcTLS) && same {
        return errors.New("TLS requires distinct HTTP and gRPC host:ports")
    }
    return nil
}

Try / catch

srv, err := server.NewServer(ctx, opts, tm, telset)
if err != nil {
    if strings.Contains(err.Error(), "same host ports") {
        return fmt.Errorf("config error: split query.http-server.host-port and query.grpc-server.host-port before enabling TLS")
    }
    return err
}

Prevention

Use different ports by convention (16686 HTTP, 16685 gRPC) in every environment.
When enabling TLS, audit the whole query extension config, not just the TLS sections.
Add a startup smoke test to CI that constructs the server with your production config.

When it happens

Trigger: Configuring the query extension with a single --query.http-server.host-port / --query.grpc-server.host-port sharing the same port while --query.http-server.tls.enabled and/or --query.grpc-server.tls.enabled is true (e.g. both set to :16686).

Common situations: Enabling TLS via config/env on an existing single-port deployment that relied on port sharing; copy-pasting the same host:port for both HTTP and gRPC sections; switching to TLS after migrating config and forgetting to split the ports.

Understand the failure class

SSL/TLS and certificate errors — how TLS handshakes and certificate validation fail.

Related errors

AI-assisted analysis of jaegertracing/jaeger@806f444784 (2026-09-01). Data as JSON: /api/errors/d0aa9a43775b1cc4. Report an issue: GitHub.