why nlb (NLB->DX->IP target) can not disable Client IP - udp traffic

As you mentioned correctly, in the case of UDP target group, client IP preservation cannot be disabled.

From the documentation:

preserve_client_ip.enabled: Indicates whether client IP preservation is enabled. The value is true or false. The default is disabled if the target group type is IP address and the target group protocol is TCP or TLS. Otherwise, the default is enabled. Client IP preservation can't be disabled for UDP and TCP_UDP target groups.

The reason is due to the nature of UDP protocol which is connectionless and doesn't have an indication on when a connection has ended (unlike TCP where you have RST and FIN flags).

If the NLB would have performed SNAT it would require it to track sessions from multiple clients and could only handle 64K sessions until all the source ports would be exhausted between the NLB and the target (which could potentially happen very quickly) because there's a single source IP (the NLB ENI address) towards the target.

NLB recently added support for SNAT with UDP when using dualstack mode where the target group are IPv6 addresses. in this case NLB uniquely assigned a /80 IPv6 address from the subnet per client. You cant read more about it in this blog post.

I think you mean "client IP preservation can't be enabled".

This is down to routing and how flows are tracked in a network. Traffic flows through a load balancer have to be symmetrical. That is, the path packets that follow from the client to the target has to be the reverse of the path that the packets from the target to the client take. This is important because the NLB rewrites the destination IP address for "inbound" packets to be the IP of the target; and for reply packets it rewrites the source IP address (which is the address of the target) to the NLB address.

This means that when the target replies to the client's packet it must return via the NLB. But if the destination IP address is (say) 53.53.53.53 (a random IP I just made up) then the path that the reply packet takes will not pass through the NLB. Because there is a high likelihood that there is a default route somewhere in the network between the target and the NLB which will take the packet somewhere else. If that happens, the client will get a reply packet from the target IP or from a NAT process somewhere else in the path. This will break the network flow because the reply packet is now not a reply to the original packet because the IP addresses (source/destination) don't match.

You might also find that such packets get dropped by firewalls and NAT devices elsewhere on the internet because those source/destination IP pairs are not the same between the original (inbound) packet from the client to the target and the reply (outbound) packet.

To fix this, when targets are outside the VPC where the NLB is the NLB also rewrites the source IP of "inbound" packets to be the private IP of the NLB. That way, the reply packets will go to the NLB where it can rewrite the destination IP (it's an outbound packet now so that is the IP of the NLB) to the original client IP.

Why does it work in a VPC? Because VPC is an emulated network and AWS can subtly modify the behaviour of reply packets so that they go via the NLB if the original packet flow came through the NLB in the first place. Once the packets leave that VPC though, the normal rules of routing take over.

The solution here is to run some sort of reverse proxy in the VPC which is the target and then inserts the original client IP (somehow) into the application data stream by modifying the packets. This means the "real" target (via Direct Connect) needs to interpret the modified packets to retrieve the client IP and then deal with the application traffic.

NLB offers this for TCP sessions using Proxy Protocol v2 but it is not a feature available for UDP.