Application-delivery paths, health and state
Model both sides of a proxy
An application-delivery design connects a client-facing service to an appropriate application endpoint. In a full-proxy arrangement the device has distinct client-side and server-side connection contexts. Connection reuse, multiplexing and protocol behavior depend on the selected profiles and implementation; one client connection does not universally imply one newly created backend connection. A virtual listener identifies the traffic offered to the service, while a pool or service group organizes eligible endpoints. Keep endpoint addresses, service ports, routing, source translation and application identity separate.
Health is a particular observation
A transport connection test and an application transaction test answer different questions. A successful TCP handshake can coexist with an unavailable database or a broken login workflow. Define the monitor destination, request, expected response, timeout and interval under the actual application and version. A green service indicator is evidence about the configured conditions at that observation time, not proof that every user action will succeed. Avoid sending privileged or destructive transactions merely to test availability. If a member is administratively disabled, distinguish its configured status from an automatic monitor failure.
Selection, persistence and session state
A selection algorithm distributes eligible new work according to its actual method. Persistence can associate later requests with a previously selected destination, which is different from the application storing a user’s session state. Source-address persistence can group unrelated users behind one translator; cookie-based approaches depend on actual protocol and client behavior. Persistence does not make a failed backend healthy. Decide how the application handles unavailable destinations, session recovery and drained connections instead of assuming that every migration preserves every transaction.
Preserve the whole return path
Source network address translation can help establish a return route through the proxy, but may hide the original client network address from the backend. A forwarded application header is a different mechanism and needs a trust boundary so untrusted clients cannot impersonate an authoritative source. TLS termination, re-encryption and pass-through have different visibility and certificate requirements. A successful front-end handshake does not establish backend trust or successful application authorization. For any proposed change, map actual flow, evidence and recovery before adjusting a production listener. Vendor object names, policy order and defaults are not interchangeable between NetScaler and F5.