Add delay_auth_write to Socks5 Client Advanced Config #2933
Conversation
Codecov ReportAttention: Patch coverage is
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## master #2933 +/- ##
==========================================
- Coverage 35.60% 35.59% -0.02%
==========================================
Files 729 729
Lines 41596 41612 +16
==========================================
Hits 14812 14812
- Misses 25149 25167 +18
+ Partials 1635 1633 -2 ☔ View full report in Codecov by Sentry. |
|
I have seen a lots of comment about people falsely accusing V2Ray's implementation of socks5 is wrong by sending socks hello packet and socks auth packet together and not waiting for server side reply. This is not true, and my decision to include this workaround is not a concession to their claim, but simply as a way to make life easier for users. In TCP, the receiver should never assume the message boundary are preserved, and should adherence to the protocol's framing method. The client are supposed to be able to use protocol pipelining to reduce the amount of roundtrip required to finish any operation when possible. When a server does failed to correctly frame the messages and the client send a combined message with protocol pipelining, the server will failed to parse the messages correctly. This is strictly server's fault of inability to process TCP message correctly, and using TCP socket as if it is a SCTP socket. But this is not how some people determine who is at fault here, their mindset is simple... If we couldn't get the server to change its behavior, then we must get the client to change its behavior. And if someone is wrong, then it better be the one that could change the behavior to be wrong, otherwise it won't work because I could not get the more stubborn party to change their behavior. This is how they survive, and they are not wrong in the way they can only demand and pressure the party that are more friendly to them to change, but they are wrong that they have to accuse that the more friendly party is wrong to get them to help them. We call this workaround, the one doing a right thing to get around the wrong thing other people are doing. The more flexible and more friendly party can help you to get things working not because they are wrong, but they want your life to be better. I didn't merge the previous suggest change from contributor, not because I insist I would only change if I am wrong, but simply because the purposed change does not match the quality standard of the project. And as today I some free time and energy, I wrote a workaround that does not compromise the code quality and design objective of project. When you are seeing injustice and abnormality from someone or something you couldn't change, work around it, keep remembering what is right and what is normal. The light within you will guide you, and don't let it submerged by sands. |
|
how to use? |
It doesn't seem to work. |
As a workaround to compensate bug in other socks5 implementations, an advanced option
delay_auth_writewas added to socks5.When this setting is enabled, the socks5 will will for an additional roundtrip before sending authentication information. This have adverse impact on connection speed, but could avoid triggering bug in some incorrect implementation of socks5 server.
Working setting example as follow:
{ "log": { "error": { "level": "Debug", "type": "Console" }, "access": { "type": "None" } }, "outbounds": [ { "protocol": "#v2ray.core.proxy.socks.ClientConfig", "settings": { "server": [ { "address": "------", "port": 4950, "user": [ { "account": { "@type": "v2ray.core.proxy.socks.Account", "username": "------", "password": "------" } } ] } ], "version": "SOCKS5", "delay_auth_write": true }, "proxySettings": { "tag": "overlay", "transportLayer": true } }, { "protocol": "vmess", "tag": "overlay", "settings": { "address": "------", "port": 443, "uuid": "------" }, "streamSettings": { "transport": "ws", "transportSettings": { "path": "v2ray", "maxEarlyData": "4096" }, "security": "tls" } } ], "inbounds": [ { "protocol": "socks", "settings": { "udpEnabled": true, "address": "127.0.0.1" }, "port": 12345, "listen": "127.0.0.1" } ] }(Fix: #2619)
(Fix: #1048)