Xray 26.7.11-26.7.28: Xray REALITY server rejects the hardcoded Xray version code sent by this software by default, causing this software unable to connect. They claims the purpose is to block clients with characteristics flaw, but it is absurd to determine the presence of such a flaw by the version code. Furthermore, the so-called "characteristics flaw" does not exist in the REALITY client implementation of this software unless the user explicitly enables the "disable REALITY X25519MLKEM768" option. Modifying the hardcoded version code does not help for all history versions of this software being blackly blocked, and can't prevent this software from being blackly blocked again in the future. Therefore, as a client-side user, you should demand that Xray, the root cause of this problem, resolve the problem, rather than demanding this software compromise itself to accommodate the issue; as a server-side user, you should boycott Xray and switch to a different server implementation. The characteristics flaw Xray claimed is in fact third-party software being forced to workaround the incompatibility issues caused by the X25519MLKEM768 breaking change created by Xray due to REALITY design limitation. However, Xray turned around and blamed third-party software.
Xray >= 26.9.8: Xray REALITY server removed the previous behavior in favor of rejecting TLS Client Hello without X25519MLKEM768 key share and TLS Client Hello with X25519MLKEM768 key share but after X25519 key share. This is also ridiculous and there is no feasible server-side workaround other than replacing Xray with other proxy software. As a result, all uTLS fingerprints other than chrome, firefox and safari will be unable to connect to Xray, and the opt-in "disable X25519MLKEM768" option will be invalid. For your information, in uTLS latest version (1.8.2), only hellochrome_148 fingerprint is compatible with such a stupid Xray server. uTLS added hellofirefox_148 and hellosafari_26_3 in recent commit but it has not been released yet, and there are tons of different TLS stacks all over the world with different characteristics. Xray called a fingerprint without X25519MLKEM768 key share a "strange fingerprint". We all know the parrot is dead, but Xray still want all client implementations to be the parrot.
Therefore, as a client-side user, you should demand that the root cause of this issue—Xray—remove all explicit restrictions and cease discriminatory practices, rather than asking the software to compromise in order to accommodate the problem; as a server-side user, you should boycott Xray, remove your Xray installation and switch to a different server implementation.
Xray 26.7.11-26.7.28: Xray REALITY server rejects the hardcoded Xray version code sent by this software by default, causing this software unable to connect. They claims the purpose is to block clients with characteristics flaw, but it is absurd to determine the presence of such a flaw by the version code. Furthermore, the so-called "characteristics flaw" does not exist in the REALITY client implementation of this software unless the user explicitly enables the "disable REALITY X25519MLKEM768" option. Modifying the hardcoded version code does not help for all history versions of this software being blackly blocked, and can't prevent this software from being blackly blocked again in the future. Therefore, as a client-side user, you should demand that Xray, the root cause of this problem, resolve the problem, rather than demanding this software compromise itself to accommodate the issue; as a server-side user, you should boycott Xray and switch to a different server implementation. The characteristics flaw Xray claimed is in fact third-party software being forced to workaround the incompatibility issues caused by the X25519MLKEM768 breaking change created by Xray due to REALITY design limitation. However, Xray turned around and blamed third-party software.
Xray >= 26.9.8: Xray REALITY server removed the previous behavior in favor of rejecting TLS Client Hello without X25519MLKEM768 key share and TLS Client Hello with X25519MLKEM768 key share but after X25519 key share. This is also ridiculous and there is no feasible server-side workaround other than replacing Xray with other proxy software. As a result, all uTLS fingerprints other than
chrome,firefoxandsafariwill be unable to connect to Xray, and the opt-in "disable X25519MLKEM768" option will be invalid. For your information, in uTLS latest version (1.8.2), onlyhellochrome_148fingerprint is compatible with such a stupid Xray server. uTLS addedhellofirefox_148andhellosafari_26_3in recent commit but it has not been released yet, and there are tons of different TLS stacks all over the world with different characteristics. Xray called a fingerprint without X25519MLKEM768 key share a "strange fingerprint". We all know the parrot is dead, but Xray still want all client implementations to be the parrot.Therefore, as a client-side user, you should demand that the root cause of this issue—Xray—remove all explicit restrictions and cease discriminatory practices, rather than asking the software to compromise in order to accommodate the problem; as a server-side user, you should boycott Xray, remove your Xray installation and switch to a different server implementation.