Match Swarm load-balancer targets to the port publication mode

Bottom line: Identify how the service publishes its port before explaining why a node answers or fails a probe. Keep the external load-balancer target list and actual task placement tied to that mode so a quiet node is not automatically treated as an invalid backend.

Source fact: documented behavior

The Use Swarm mode routing mesh documentation is the primary reference.

The Swarm ingress routing mesh accepts published-port connections on nodes even when a service task is not running on that node, then routes them to an active container. With host publication, a node without a service task does not provide that service on the port; another application might be listening there instead. For the documented routing-mesh load-balancer arrangement, every swarm node can be a target, and task movement does not require reconfiguring that external load balancer.

What the source does not establish

This article selects the target population appropriate to the documented publication mode. It does not approve firewall exposure, choose a universal health probe or establish application availability. Keep DNS round-robin endpoint mode and routing-mesh bypass design under their exact additional requirements. A TCP response alone should not establish that the intended service handled the request.

Applicability questions

• Does the service use ingress or host publication?
• Which nodes currently run its tasks?
• Which nodes does the external load balancer target?
• What application response will identify the intended backend service?

DSE recommendation: review mode before editing the backend list

DSE recommends reviewing publication mode and task placement together before changing Swarm load-balancer targets.

Obtain the current supported service inspection and load-balancer configuration. Record the published port, target port, protocol and publication mode without copying example addresses into the design. Map current task locations separately from the backend-node list. Ask the service owner to explain which relationship the selected mode is intended to create.

Review a node with no local task as a specific case. For an ingress design, inspect the expected routed application path. For a host-mode design, identify which nodes should actually provide the service and how the external configuration follows that population. Preserve an unrelated listener as a finding instead of counting any open port as a healthy service instance.

Have the network owner review allowed load-balancer-to-node reachability through the approved filtering arrangement. Keep that reachability decision separate from whether a task is local. Avoid disabling host or Docker networking controls merely because a backend probe disagrees with the current spreadsheet.

Plan the treatment of task movement and node maintenance before changing the target list. Identify who owns membership updates where the design requires them. Retain the previous service and load-balancer revisions so an unexpected route can be investigated without changing both systems repeatedly.

Verification and evidence

Proposed verification, not performed: use a disposable service and authorized load balancer in a test swarm. Record a node with a task and a node without one, then predict the intended application-level response under the chosen publication mode.

Exercise only the approved mode and collect sanitized service inspection, task placement, target configuration and actual requests. A separate host-mode comparison needs its own supported arrangement and explicit targets. If task movement is part of the accepted test, observe the resulting path rather than inferring it from a healthy probe. Keep protocol reachability, correct application identity and recovery timing as distinct observations.

Official references

• Use Swarm mode routing mesh — Docker Docs.

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.