Players of a game receive errors from a target that the Network Load Balancer still marks healthy. The target group health check is a TCP check on the listener port. What should operators investigate?
Select an answer to reveal the explanation.
Short Explanation
A door that opens does not mean the shop inside is serving anyone. Your TCP health check stays green when the port accepts a connection, even while the game returns errors. The trap is trusting the load balancer light for a failure that lives in the application.
Full Explanation
A Network Load Balancer TCP health check succeeds when the target completes the TCP handshake on the checked port. It does not send the players' request and does not read an error body, so a process can accept the connection and still return application errors. The healthy mark therefore does not explain the player-facing symptom, and the application on that target is the layer that matches the errors. Subnet route tables are the wrong place to look once the handshake has succeeded, because the checker already reached the port. The scheme, internet-facing or internal, controls who can connect to the load balancer and does not make a TCP check inspect an application response. Deletion protection only stops the load balancer from being deleted and does not decide target health. If the check is later changed to HTTP or HTTPS, the path and success codes have to match a real health response or healthy targets will flap. From a client, repeat the action the players use against that target and compare the error with the TCP result.