swap vmess for vless httpupgrade (non-tls) with encryption#113
Merged
Conversation
Drop the vmess-ws-cdn inbound and replace it with a VLESS httpupgrade pair carried over plain HTTP, fronted by nginx like the existing hu-tls inbounds. Confidentiality comes from VLESS Encryption (post-quantum ML-KEM-768 + X25519 AEAD) inside the stream instead of TLS, so no cert is needed. - inbounds.json: vless-hu-direct (xray:8005) and vless-hu-cdn (xray:8055), decryption set to the mlkem768x25519plus string; links carry the matching encryption= value. - config.py: derive the X25519 keypair deterministically from the identifier (same as REALITY) so links survive redeploys; guard that drops the inbounds if key gen fails, mirroring the REALITY/TLS guards. - nginx: plaintext :8080 server block (both paths), replica include for 8080; CF fronts the CDN variant over HTTP on 8080. - docker-compose: move the 8080 publish from xray to nginx. Firewall port list is unchanged (8080 was already open for vmess).
xorpub masks the handshake public key against DPI at near-zero cost; stock padding hides handshake length while keeping us in the common crowd. Keeps X25519 auth + 0rtt for fast, battery-friendly reconnects.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Replaces the
vmess-ws-cdninbound with a VLESS httpUpgrade pair carried over plain HTTP and fronted by nginx, matching the existingvless-hu-tls-*setup. Since there's no TLS, confidentiality comes from VLESS Encryption (post-quantum ML-KEM-768 + X25519 AEAD) negotiated inside the stream.What changed
vmess-ws-cdn; addvless-hu-direct(xray:8005) andvless-hu-cdn(xray:8055). Serverdecryption=mlkem768x25519plus.native.600s.<PrivateKey>; links carry the matchingencryption=mlkem768x25519plus.native.0rtt.<Password>._setup_vless_encryption()derives the X25519 keypair deterministically from the node identifier (same trick as REALITY), so links survive redeploys with no key material persisted. A guard drops these inbounds if key gen fails, mirroring the REALITY/TLS guards, so a bad string never takes downxray -test.:8080server block with both paths + thelocations.d/8080replica include. CF fronts the CDN variant over HTTP on 8080 (same port vmess used).8080publish fromxraytonginx.The host firewall list is unchanged (8080 was already open for vmess). Deaf-port healing (#111) picks up 8005/8055 automatically since it's driven off the config.
Format source
decryption/encryptionstring format follows Xray-core PR #5067 (VLESS post-quantum encryption); X25519-only auth,nativemode, padding omitted (optional).Needs live validation
Can't run xray/nginx locally. On a test server please confirm:
xray -testpasses with the generated config (both direct + cdn).nginx -tpasses and the:8080block loads.xray-knifeparses theencryption=link param; if not, the health metric will read these as down even though they work.