Replies: 1 comment 4 replies
-
yes
If this is a concern, you can remove VLESS and replace it with SS or VMESS. I think "SS-in-VLESS-in-WS/GRPC" sounds overly complicated but I don't know enough to tell whether it is a problem for detectability.
it is already nested TLS anyway (CDN's TLS and user's TLS), and there's not much you can do about it. vision fixes tls-in-tls by "violating" the outer TLS, the CDN does not allow for that. |
Beta Was this translation helpful? Give feedback.
-
|
I want to keep using CDN for now. Switching transports and chaining is easy with Xray but I'm not sure about unexpected caveats. I mentioned [something]-in-VLESS because I assumed VLESS is the most suitable "first layer" protocol for Xray-core clients. Apparently, SS works fine on its own over CDN. I tried some other combinations. Not much of a performance hit even for overly complicated nesting which is great.
Depends on traffic you proxy. Still, majority would be TLS in TLS anyway, true. |
Beta Was this translation helpful? Give feedback.
-
Actually scratch that. My initial huntch was correct. It's much less stable even then nested VLESS. |
Beta Was this translation helpful? Give feedback.
-
|
I am not sure I understand. Are you saying that you are nesting SS in VLESS, then put that datastream inside websocket/grpc/httpupgrade to funnel it through the CDN? and that this is more stable than SS+WS/GRPC/...? |
Beta Was this translation helpful? Give feedback.
-
|
SS+WS or SS in VLESS+WS appears to be less stable then VLESS in VLESS+WS. YMMV. |
Beta Was this translation helpful? Give feedback.
-
VLESS does not provide its own encryption. CDN terminates TLS at the edge. I assume CDN provider can see which domain/IP I request through VLESS, my inbound user id and my plain text data (like HTTP traffic on port 80). Is this correct?
I can wrap VLESS+TLS in VLESS+TLS-CDN but then it's nested TLS. Should I switch to SS in VLESS?
What would be a good solution?
Beta Was this translation helpful? Give feedback.
All reactions