hyperledger/fabric · error

could not connect to ordering service

Error message

could not connect to ordering service

What it means

This error is wrapped by newHeaderClient in the BFT censorship monitor when m.requester.Connect() fails to establish a deliver stream to the ordering service for a given endpoint. It means the monitor could not obtain a deliver client to receive block headers, so header receivers cannot be launched. The original transport/dial error is wrapped with the message "could not connect to ordering service".

Source

Thrown at common/deliverclient/blocksprovider/bft_censorship_monitor.go:403

	if !blockTime.IsZero() {
		blockNumber++ // If blockTime.IsZero(), we request block number 0, else blockNumber+1
	}

	if prevHeaderReceiver != nil {
		hNum, _, errH := prevHeaderReceiver.LastBlockNum()
		if errH == nil && (hNum+1) > blockNumber {
			blockNumber = hNum + 1
		}
	}

	seekInfoEnv, err := m.requester.SeekInfoHeadersFrom(blockNumber)
	if err != nil {
		return nil, nil, errors.Wrap(err, "could not create a signed Deliver SeekInfo message, something is critically wrong")
	}

	deliverClient, clientCloser, err = m.requester.Connect(seekInfoEnv, endpoint)
	if err != nil {
		return nil, nil, errors.Wrap(err, "could not connect to ordering service")
	}

	return deliverClient, clientCloser, nil
}

View on GitHub (pinned to 2736b63f8f)

Solutions

  1. Verify the orderer endpoint (host:port) is reachable: nc/telnet to the address and confirm the orderer peer is running.
  2. Check TLS configuration: ensure the client's tlscerts/channel crypto material matches the orderer's TLS CA and the certificate SANs include the orderer hostname.
  3. Confirm channel configuration contains correct orderer addresses; update via configtx/config update if orderers changed.
  4. Inspect orderer logs for deliver-side rejections and check network/firewall/DNS between client and orderer.

Example fix

// before: orderer TLS CA missing from channel config -> Connect fails
// after: correct TLS root certs in peer config and channel orderer endpoints
export FABRIC_CFG_PATH=/path/to/config
# ensure peer channel TLS root certs contain orderer CA, then restart peer
Defensive patterns

Strategy: retry

Validate before calling

// pre-check endpoint reachability before launching the monitor
func checkOrdererReachable(addr string) error {
    conn, err := net.DialTimeout("tcp", addr, 3*time.Second)
    if err != nil {
        return fmt.Errorf("orderer %s unreachable: %w", addr, err)
    }
    conn.Close()
    return nil
}

Try / catch

deliverClient, closer, err := newHeaderClient(...)
if err != nil {
    var nested *wrpErr
    if errors.As(err, &nested) && strings.Contains(err.Error(), "could not connect to ordering service") {
        // log and retry with backoff / rotate endpoint
        time.Sleep(backoff)
        return retryNewHeaderClient()
    }
    return err
}

Prevention

When it happens

Trigger: newHeaderClient calls m.requester.Connect(seekInfoEnv, endpoint) with a signed Deliver SeekInfo envelope; any error returned by Connect (dial failure, TLS handshake failure, endpoint unreachable) is wrapped with this message and returned to launchHeaderReceivers, aborting the monitor's header-receiver setup.

Common situations: Orderer endpoint is down or misconfigured in channel config; TLS root certificates are wrong or expired; the orderer address resolves but the deliver port is blocked by a firewall; DNS failures in Kubernetes/Docker networks; stale orderer addresses after orderer set changes.

Related errors


AI-assisted analysis of hyperledger/fabric@2736b63f8f (2026-09-04). Data as JSON: /api/errors/32d73a9ebe5fe57f. Report an issue: GitHub.