What causes "error getting address for check %q: %v" in hashicorp/nomad?

Correct the check's port to an existing network port label

error getting address for check %q: %v

Error message

error getting address for check %q: %v

What it means

For each task-level check that specifies its own address_mode or port label differing from the service, Nomad calls serviceregistration.GetAddress to resolve the check's host/port. Failures (unknown port label, unsupported address mode, no matching network) are wrapped in this message and the whole set of registrations fails to build.

Source

Thrown at command/agent/consul/service_client.go:1515

			}

			addrMode := check.AddressMode
			if addrMode == "" {
				if service.Address != "" {
					// if the service is using a custom address, enable the check
					// to use that address
					addrMode = structs.AddressModeAuto
				} else {
					// otherwise default to the host address
					addrMode = structs.AddressModeHost
				}
			}

			var err error
			ip, port, err = serviceregistration.GetAddress(
				service.Address, addrMode, portLabel, workload.Networks, workload.DriverNetwork, workload.Ports, workload.NetworkStatus)
			if err != nil {
				return nil, fmt.Errorf("error getting address for check %q: %v", check.Name, err)
			}
		}

		checkID := MakeCheckID(serviceID, check)
		registration, err := createCheckReg(serviceID, checkID, check, ip, port, workload.ProviderNamespace)
		if err != nil {
			return nil, fmt.Errorf("failed to add check %q: %v", check.Name, err)
		}
		sreg.CheckOnUpdate[checkID] = check.OnUpdate
		registrations = append(registrations, registration)
	}

	return registrations, nil
}

// RegisterWorkload with Consul. Adds all service entries and checks to Consul.
//
// If the service IP is set it used as the address in the service registration.

View on GitHub (pinned to 482b49bf1a)

Solutions

Correct the check's port to an existing network port label
Remove or fix the check-level address_mode (or inherit the service address by deleting check address fields)
Confirm the group network block declares the port and the allocation has a NetworkStatus
Inspect the wrapped %v detail to see whether it's a missing label vs unsupported mode

Example fix

// before
check {
  type = "tcp"
  address_mode = "driver"
}
// after
check {
  type = "tcp"
  address_mode = "host"
  port = "http"
}

Defensive patterns

Strategy: validation

Validate before calling

// Check-level port label must resolve in the group network
for _, c := range svc.Checks {
  if c.PortLabel != "" {
    if _, ok := ports[c.PortLabel]; !ok {
      return fmt.Errorf("check %q references undeclared port %q", c.Name, c.PortLabel)
    }
  }
  if c.AddressMode == "driver" {
    return fmt.Errorf("check %q: driver address_mode requires a driver network", c.Name)
  }
}

Prevention

Only override check address/port when necessary — inherit the service's
Never use address_mode='driver' on drivers without network support
Validate jobs with `nomad job validate` before submission
Keep check port labels identical to declared network ports

When it happens

Trigger: BuildRegistrations loop reaches a check whose address must be resolved independently and GetAddress(service.Address, addrMode, portLabel, networks, driverNetwork, ports, networkStatus) returns an error — check port label not declared, address_mode 'driver' without DriverNetwork, etc.

Common situations: Check block with port = "admin" not present in network block; check-level address_mode = 'driver' on non-networked drivers; task running without network status yet (allocation not scheduled on a network).

Related errors

AI-assisted analysis of hashicorp/nomad@482b49bf1a (2026-09-04). Data as JSON: /api/errors/c776546e0c315f1b. Report an issue: GitHub.