Key takeaways
Target and serverName have separate roles
In current Xray configuration, target is the server-side REALITY field and the older dest name remains an alias. REALITY interacts with the real target during the TLS process, so the value is operational rather than decorative. serverNames defines which client serverName values the server accepts.
Those names are normally kept consistent with the target and with SNI values the destination actually handles. Certificate SAN values and observed TLS behavior are practical references. An arbitrary name that has no relationship with the selected target can produce unusual and fragile behavior.
Why magic SNI lists are a weak configuration method
There is no single domain that is ideal for every server, region, and network. A domain can use a CDN, change addresses, produce different regional behavior, or stop matching the deployment assumptions. Popularity does not guarantee certificate compatibility and does not automatically make a connection harder to classify.
Unauthenticated REALITY traffic can also be forwarded toward the target. This means target selection affects fallback operation as well as handshake appearance. Some targets require additional controls so the server is not turned into an unintended forwarding path.
Validate the target before rollout
Confirm that the REALITY server can reliably reach the target on the intended port, that the expected SNI is accepted, and that the returned certificate matches the design. Use Xray TLS diagnostics instead of copying values from an unverified list. The client serverName must be one of the values allowed by the server.
After a target or serverName change, test a fresh connection, several independent destinations, repeated handshakes, and reconnect behavior. Change one parameter class at a time so a rollback can identify the actual cause of failure.
Continue reading