Operating system
Windows
System version
Windows 10 Pro
Installation type
zip
Version
1.1.2
Description
Hello,
I encountered an issue related to proxy chaining when using different cores inside Throne.
As I understand, Throne uses:
- sing-box core for most proxy types (SOCKS, Shadowsocks, Trojan, etc.)
- Xray core specifically for VLESS with XHTTP transport (since sing-box does not support XHTTP)
This design works fine for individual connections, but causes problems when building proxy chains.
Problem
If at least one node in the chain is a VLESS + XHTTP proxy, the entire chain fails to establish a connection.
Most likely, this happens because:
- the first proxy (e.g. SOCKS5) is handled by sing-box
- the next proxy (VLESS + XHTTP) is handled by Xray
These cores do not seem to work together within a single proxy chain.
Suggestion
It would be very useful to allow users to manually select which core is used for each proxy type.
Since Xray is already included in Throne, one possible solution:
- Allow mapping proxy types to cores (e.g. use Xray for SOCKS/HTTP if needed)
- Or allow selecting the core per proxy or per group
I understand that some protocols are only supported by one core, and full compatibility may not always be possible. However, many common protocols are supported by both cores:
- HTTP
- SOCKS
- Shadowsocks
- Trojan
Allowing flexible core selection would make proxy chaining much more reliable.
A similar approach is implemented in v2rayN for Windows, where users can choose which core handles specific connections.
Why this matters
Currently, if a user has a group of VLESS + XHTTP proxies, it becomes impossible to use them in chains (e.g. via SOCKS5), even though both cores are already available in the application.
This limits one of the key use cases — chaining proxies to bypass restrictions.
If needed, I can provide logs or additional test cases.
Thank you for your work!
Reproduction
Add a SOCKS5 proxy
2.
Add a subscription (proxy list) into a separate group (containing VLESS + XHTTP proxies)
3.
Open group settings
4.
Set the SOCKS5 proxy as front proxy (to route all connections through it)
5.
Try to connect to any vless+xhttp proxy in the group (SOCKS5 → VLESS XHTTP)
Actual behavior
No connection is established for any proxy in the group.
Logs
Operating system
Windows
System version
Windows 10 Pro
Installation type
zip
Version
1.1.2
Description
Hello,
I encountered an issue related to proxy chaining when using different cores inside Throne.
As I understand, Throne uses:
This design works fine for individual connections, but causes problems when building proxy chains.
Problem
If at least one node in the chain is a VLESS + XHTTP proxy, the entire chain fails to establish a connection.
Most likely, this happens because:
These cores do not seem to work together within a single proxy chain.
Suggestion
It would be very useful to allow users to manually select which core is used for each proxy type.
Since Xray is already included in Throne, one possible solution:
I understand that some protocols are only supported by one core, and full compatibility may not always be possible. However, many common protocols are supported by both cores:
Allowing flexible core selection would make proxy chaining much more reliable.
A similar approach is implemented in v2rayN for Windows, where users can choose which core handles specific connections.
Why this matters
Currently, if a user has a group of VLESS + XHTTP proxies, it becomes impossible to use them in chains (e.g. via SOCKS5), even though both cores are already available in the application.
This limits one of the key use cases — chaining proxies to bypass restrictions.
If needed, I can provide logs or additional test cases.
Thank you for your work!
Reproduction
Add a SOCKS5 proxy
2.
Add a subscription (proxy list) into a separate group (containing VLESS + XHTTP proxies)
3.
Open group settings
4.
Set the SOCKS5 proxy as front proxy (to route all connections through it)
5.
Try to connect to any vless+xhttp proxy in the group (SOCKS5 → VLESS XHTTP)
Actual behavior
No connection is established for any proxy in the group.
Logs