mirror of
https://github.com/MHSanaei/3x-ui.git
synced 2026-11-12 16:15:02 +03:00
fix(inbounds): refuse 2022-blake3-chacha20-poly1305 on shadowsocks inbounds
xray-core builds a Shadowsocks-2022 inbound with users only for the AES methods: the multi-user identity header is AES-only, so the config builder and the multi-user server both reject chacha20. Every panel inbound carries clients, so picking 2022-blake3-chacha20-poly1305 in the inbound form kept the whole core from starting; its links also failed on the client with "multi-key is not supported". The inbound form no longer offers the method and AddInbound/UpdateInbound reject it. Startup moves stored inbounds to 2022-blake3-aes-256-gcm, which takes the same 32-byte keys, so every stored key stays valid. Outbounds keep the method, since a single-key outbound to such a server works. The share-link generator drops the single-user branch that only this method reached.
This commit is contained in:
@@ -219,8 +219,9 @@ keys from the panel's VLESS settings.
|
||||
## Shadowsocks ciphers
|
||||
|
||||
Shadowsocks inbounds support both classic ciphers and **Shadowsocks-2022**
|
||||
(method names starting with `2022-blake3-`). Most ciphers are multi-user;
|
||||
`2022-blake3-chacha20-poly1305` is single-user.
|
||||
(method names starting with `2022-blake3-`). `2022-blake3-chacha20-poly1305` is not
|
||||
offered for inbounds: Xray-core supports it only without users, and every panel
|
||||
inbound has clients. Outbounds can still use it.
|
||||
|
||||
<Callout type="info">
|
||||
Transports and security must match on both ends. The client's share link
|
||||
|
||||
Reference in New Issue
Block a user