发现新大陆！！！！

[ghost]

我刚刚(今晚)发现v2ray的一种新的用法，不知道前人有没有发现的，去网上查了下，目前没有查到撞车的。具体内容如下：

为了更好地隐藏流量的特征，所以有了v2ray+tls+web，这里用nginx作为web服务器，所以就是v2ray+tls+nginx。然后我们知道tls是一层加密，然后vmess协议又是一层加密，虽然用了tls以后加密方式可以选none，但vmess协议仍然要比较大的计算量。Trojan就是在这方面改进来的，就它是直接tls加密发送过来，所以就要快一点点，参考：https://www.youtube.com/watch?v=zlOTrR1AzpA&t=44s。

然后我就一直在想方法解决这个问题，我认为socks协议肯定比vmess协议计算量小，因为平时我们用v2ray或者ss，ssr，最终都出来一个socks5协议给我们连接，打游戏什么的都要通过那里，所以这不可能计算量太大的。然后完了socks也没有那么多的加密什么什么的，也不用像vmess那样有基于时间的计算。还有就是我个人的原因，因为我多打游戏，v2ray官网上写着“喜欢玩网游的朋友可能要失望了，使用 V2Ray 加速游戏效果不是很好。”，我不知道什么原因，它也没明说，我个人用着打游戏还不错。但是我知道socks协议用来打游戏肯定是没问题的。所以我想试着搞出v2ray+ws+tls，然后不同的地方是v2ray使用的协议是socks，而不是vmess。

然后就是摸索了，照狐狸画瓢，最终是成功了，应该还有可以改进的地方，我把服务端和客户端的配置文件放在这里

服务端：

{
  "inbounds": [{
    "port": 41357,
    "listen": "127.0.0.1",
    "protocol": "socks",
"sniffing":
{
        "enabled": true,
        "destOverride": ["http", "tls"]
},
"settings":
{
  "auth": "noauth",
  "udp": false,
  //"ip": "127.0.0.1",
  "userLevel": 10
},
"streamSettings":{"network":"ws","wsSettings":{"path":"/e75500"}}
  }],
  "outbounds": [{
    "protocol": "freedom",
    "settings": {}
  }]
}

nginx的配置和普通的v2ray+ws+tls相同

客户端：

{
  "inbounds": [{
       "port": 10808,
      "protocol": "socks",
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls"]
      },
      "settings": {
        "auth": "noauth",
        "udp": false
      }
  }],
  "outbounds": [{
      "protocol": "socks",
      "settings":
{
  "servers": [{
    "address": "你的域名",
    "port": 443
  }]
},
    "streamSettings":
      {
        "network": "ws",
        "security": "tls",
        "wsSettings":
        {
          "path": "/e75500"
        }
      }
  }]
}

然后接下来是测试，效果十分显著！！我在虚拟机(ubuntu)上开v2ray服务，然后在主机上连上v2ray的socks5出口，看youtube 8k，相当于半个软路由，原来v2ray占用了cpu100%的时候，现在只有20%，大多数时候只占用不到5%，这个cpu占用是在虚拟机里用top命令查看的，说明计算量确实是降低许多。不知道和trajon比如何，我家网络环境差，试不了

[ghost]

今天对这种连接方式研究了一下，首先是对配置文件改进了一下。客户端配置文件已经可以在v2rayn和v2rayng上正常使用，并且弄好了udp转发。 服务端：

{
  "inbounds": [
    {
      "port": 41357,
      "listen": "127.0.0.1",
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": false,
        "userLevel": 999
      },
      "streamSettings": {
        "network":"ws",
        "wsSettings": {
          "path":"/e75500"
        }
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",
      "settings": {}
    }
  ]
}

除了6-11行，其他设置与普通的v2ray+ws+tls没有区别，nginx部分的配置也是与普通的v2ray+ws+tls没有区别。 客户端：

{
  "log": {
    "access": "",
    "error": "",
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls"]
      },
      "settings": {
        "auth": "noauth",
        "userLevel": 10,
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "你的域名",
            "level": 10,
            "port": 443
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "wsSettings": {
          "path": "/e75500"          //这里填你的path
        }
      },
      "mux": {
        "enabled": true,
        "concurrency": 8
      }
    }
  ]
}

把域名和path修改一下，就可以正常使用了，导入到v2rayn/v2rayng中即可。

然后是体验方面的实验结果，和普通的v2ray+ws+tls相比，除了上面说的cpu占用率大降，还有就是速度。速度在带宽方面我用不出区别，主要是因为我家网速太慢了，就30mbps，两种方式都能把我家带宽轻松填满。其次就是延迟，这个提升十分显著。如图，在手机上，这个应该是测的真直连延迟，以前最低都要200ms，而现在都在80ms以内，而且我的宽带ping服务器延迟本来就有40-80ms左右，说明协议的计算带来的延迟几乎没有，这对像我一样要打游戏的简直是个福音。 然后就是以此类推，http2，应该也可以用这种方法。

最后就是如果你正在使用cdn，一定要保证cdn是可靠可信的，因为cdn中转的时候是会将你的tls解密的，再重新加密发送到你的客户端。即使是普通的v2ray+ws+tls，如果你在使用cdn，那么cdn应该是可以知道你在使用v2ray的。其次就是如果你用这种方法连接，一定要保证你的域名和path，不能同时让别人知道，一般来说域名是对外公开的，所以path最好复杂一点。

[xhqpp]

就是说把原来配置里服务端的inbounds和客户端的outbounds改成socks？

[DolorHunter]

补充一下: 根据 官方文档 对于socks的描述, 可以在 socks 协议中加入用户和密码, 牺牲部分性能换取安全性, 相当于 vmess 协议中的 uuid. 对比两个协议, 似乎只有 alterID 无法照搬, 然而 socks 延迟可以大降, 似乎很不错.

{
  "user": "test user",
  "pass": "test pass",
  "level": 0
}

[ghost]

补充一下: 根据 官方文档 对于socks的描述, 可以在 socks 协议中加入用户和密码, 牺牲部分性能换取安全性, 相当于 vmess 协议中的 uuid. 对比两个协议, 似乎只有 alterID 无法照搬, 然而 socks 延迟可以大降, 似乎很不错.

{
  "user": "test user",
  "pass": "test pass",
  "level": 0
}

1.安全性：

socks协议即使用了用户名密码，安全性也不会增加，因为没有对流量进行加密。使用了socks进行公网传输，就没有任何安全性而言，这也是为什么官方文档说不建议用socks进行公网传输。 shadowsocks协议就是在socks5的基础上加上加密改进而来。 所以这种方法的安全性完全依赖于TLS的加密，并且TLS的安全性是值得信赖的，这便是这种方案的可行性。

2.性能：

socks5即使加上用户名密码，计算量的增加几乎不变(因为没有加密)，与vmess的计算量相比依然是天壤之别(即使vmess协议的加密方式选择none)。

[DolorHunter]

@kirin10000 感谢指正

[ghost]

v2ray(socks)+websocket+tls+web搭建选项现已加入V2Ray-WebSocket(ws)+TLS(1.3)+Web搭建-管理脚本 https://github.com/kirin10000/V2Ray-WebSocket-TLS-Web-setup-script

[yaoha]

求助，v2rayN如何导入新玩法的client配置？

{
  "log": {
    "access": "",
    "error": "",
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls"]
      },
      "settings": {
        "auth": "noauth",
        "userLevel": 10,
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "www.xxxl.club",
            "level": 10,
            "port": 443
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "wsSettings": {
          "path": "/xxxxx"
        }
      },
      "mux": {
        "enabled": true,
        "concurrency": 8
      }
    }
  ]
}

[ghost]

求助，v2rayN如何导入新玩法的client配置？

{
  "log": {
    "access": "",
    "error": "",
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls"]
      },
      "settings": {
        "auth": "noauth",
        "userLevel": 10,
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "www.xxxl.club",
            "level": 10,
            "port": 443
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "wsSettings": {
          "path": "/xxxxx"
        }
      },
      "mux": {
        "enabled": true,
        "concurrency": 8
      }
    }
  ]
}

新建文本文档，把内容写入，然后将后缀改为.json，再选择导入文件

[NiceBowl335]

v2ray(socks)+websocket+tls+web搭建选项现已加入V2Ray-WebSocket(ws)+TLS(1.3)+Web搭建-管理脚本 https://github.com/kirin10000/V2Ray-WebSocket-TLS-Web-setup-script

请问一下（对于玄学断连有奇效）的原理大概是什么呢？

[ghost]

v2ray(socks)+websocket+tls+web搭建选项现已加入V2Ray-WebSocket(ws)+TLS(1.3)+Web搭建-管理脚本 https://github.com/kirin10000/V2Ray-WebSocket-TLS-Web-setup-script

请问一下（对于玄学短连有奇效）的原理大概是什么呢？

我要是懂，我就不是写玄学了，而是把原因写出来

[KirbyKFC]

这个想法之前在loc见人提过，当时我第一想法是不大行，原因如下：

• ws基于TCP
• socks5的UDP转发基于UDP而非UDP over TCP。

可能产生的情况：

1. UDP不通
2. 客户端与服务端之间新建了一条UDP隧道，明文传输数据。
3. 设想有误，传输正常。

具体什么情况我需要测试验证

[ghost]

这个想法之前在loc见人提过，当时我第一想法是不大行，原因如下：

• ws基于TCP
• socks5的UDP转发基于UDP而非UDP over TCP。

可能产生的情况：

1. UDP不通
2. 客户端与服务端之间新建了一条UDP隧道，明文传输数据。
3. 设想有误，传输正常。

具体什么情况我需要测试验证

你说的我听不太懂，只能根据我听得懂的部分回答。

先说明一些事实：

1.udp转发正常 2.与服务器没有建立udp连接，包括v2ray服务的本地端口，以及nginx对外的443端口 3.cdn可以正常使用(cdn仅支持443端口的https连接和80端口的http连接，我没有开启http3(quic)，所以不可能建立udp连接)

目前没有发现和普通v2ray+ws+tls功能上有区别。

然后再是对你说的进行解释：

ws基于tcp，确实如此，vmess也是通过tcp传输，socks5同时支持tcp和udp，因此也不矛盾，我在服务端设置了socks5 udp false。vmess不支持tcp，v2ray集成了udp转发的功能，配合多线路复用即可 总得来说就是，客户端本地的socks服务器(inbounds)，开启udp，然后开启多线路复用，v2ray自动将udp的数据合并到tcp中，一起通过第二个socks连接，这个连接的连接对象是v2ray客户端与v2ray服务端，原来这里就是vmess了，那么这个socks连接，他就不需要udp了，只需建立tcp连接即可。开启udp的是本地的socks连接，连接对象是你的应用程序和v2ray客户端，一般端口是10808。

[KirbyKFC]

这个想法之前在loc见人提过，当时我第一想法是不大行，原因如下：

• ws基于TCP
• socks5的UDP转发基于UDP而非UDP over TCP。

可能产生的情况：

1. UDP不通
2. 客户端与服务端之间新建了一条UDP隧道，明文传输数据。
3. 设想有误，传输正常。

具体什么情况我需要测试验证

初步测试结束，UDP不通。 附Log

2020/02/03 08:49:02 [Info] v2ray.com/core/app/dispatcher: taking detour [proxy] for [udp:8.8.8.8:53]
2020/02/03 08:49:02 [Info] v2ray.com/core/transport/internet/websocket: creating connection to tcp:xxx.xxx.xxx.xxx:443
2020/02/03 08:49:06 [Info] v2ray.com/core/app/dns: failed to lookup ip for domain google.com at server UDP:8.8.8.8:53 > context deadline exceeded
2020/02/03 08:49:06 [Info] v2ray.com/core/proxy/dns: ip query > v2ray.com/core/app/dns: returning nil for domain google.com > context deadline exceeded
2020/02/03 08:49:06 [Info] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/socks: connection ends > context canceled
2020/02/03 08:49:06 [Info] v2ray.com/core/transport/internet/udp: failed to handle UDP input > io: read/write on closed pipe

---

1.udp转发正常

你这里大概只测试了从本机到客户端的UDP连接，需要测试的是从客户端到服务端的UDP连接。

[ghost]

这个想法之前在loc见人提过，当时我第一想法是不大行，原因如下：

• ws基于TCP
• socks5的UDP转发基于UDP而非UDP over TCP。

可能产生的情况：

1. UDP不通
2. 客户端与服务端之间新建了一条UDP隧道，明文传输数据。
3. 设想有误，传输正常。

具体什么情况我需要测试验证

初步测试结束，UDP不通。 附Log

2020/02/03 08:49:02 [Info] v2ray.com/core/app/dispatcher: taking detour [proxy] for [udp:8.8.8.8:53]
2020/02/03 08:49:02 [Info] v2ray.com/core/transport/internet/websocket: creating connection to tcp:xxx.xxx.xxx.xxx:443
2020/02/03 08:49:06 [Info] v2ray.com/core/app/dns: failed to lookup ip for domain google.com at server UDP:8.8.8.8:53 > context deadline exceeded
2020/02/03 08:49:06 [Info] v2ray.com/core/proxy/dns: ip query > v2ray.com/core/app/dns: returning nil for domain google.com > context deadline exceeded
2020/02/03 08:49:06 [Info] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/socks: connection ends > context canceled
2020/02/03 08:49:06 [Info] v2ray.com/core/transport/internet/udp: failed to handle UDP input > io: read/write on closed pipe

udp转发成功，我在cmd里按一下查询dns，log就出现一行。 请检查你的配置文件是否与我第一次回复中的相同，我最开始提供的配置文件确实不能udp转发。 最简单的办法就是，你先写个vmess+ws+tls的配置文件，实现udp转发，然后再把配置文件中的vmess改成socks

[ghost]

今天对这种连接方式研究了一下，首先是对配置文件改进了一下。客户端配置文件已经可以在v2rayn和v2rayng上正常使用，并且弄好了udp转发。 服务端：

{
  "inbounds": [
    {
      "port": 41357,
      "listen": "127.0.0.1",
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": false,
        "userLevel": 999
      },
      "streamSettings": {
        "network":"ws",
        "wsSettings": {
          "path":"/e75500"
        }
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",
      "settings": {}
    }
  ]
}

除了6-11行，其他设置与普通的v2ray+ws+tls没有区别，nginx部分的配置也是与普通的v2ray+ws+tls没有区别。 客户端：

{
  "log": {
    "access": "",
    "error": "",
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls"]
      },
      "settings": {
        "auth": "noauth",
        "userLevel": 10,
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "你的域名",
            "level": 10,
            "port": 443
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "wsSettings": {
          "path": "/e75500"          //这里填你的path
        }
      },
      "mux": {
        "enabled": true,
        "concurrency": 8
      }
    }
  ]
}

把域名和path修改一下，就可以正常使用了，导入到v2rayn/v2rayng中即可。

然后是体验方面的实验结果，和普通的v2ray+ws+tls相比，除了上面说的cpu占用率大降，还有就是速度。速度在带宽方面我用不出区别，主要是因为我家网速太慢了，就30mbps，两种方式都能把我家带宽轻松填满。其次就是延迟，这个提升十分显著。如图，在手机上，这个应该是测的真直连延迟，以前最低都要200ms，而现在都在80ms以内，而且我的宽带ping服务器延迟本来就有40-80ms左右，说明协议的计算带来的延迟几乎没有，这对像我一样要打游戏的简直是个福音。 然后就是以此类推，http2，应该也可以用这种方法。

最后就是如果你正在使用cdn，一定要保证cdn是可靠可信的，因为cdn中转的时候是会将你的tls解密的，再重新加密发送到你的客户端。即使是普通的v2ray+ws+tls，如果你在使用cdn，那么cdn应该是可以知道你在使用v2ray的。其次就是如果你用这种方法连接，一定要保证你的域名和path，不能同时让别人知道，一般来说域名是对外公开的，所以path最好复杂一点。

勘误

经多次测试，这里延迟的显著降低实为多线路复用(mux)的结果，实际上延迟确实有降低，但没有这么明显。在这里对比的vmess+ws+tls没有开启mux，实验不严谨。但我不是故意这么弄的，因为从v2rayn客户端导出完整的客户端配置中有mux，所以我以为v2rayng也开默认启了mux。实际上v2rayng没有开启mux。 在相同条件下测试，延迟大约降低25%左右。

计算量确实是降低非常多，相同的8k视频，vmess+ws+tls与socks+ws+tls对比如下：

[ghost]

这个想法之前在loc见人提过，当时我第一想法是不大行，原因如下：

• ws基于TCP
• socks5的UDP转发基于UDP而非UDP over TCP。

可能产生的情况：

1. UDP不通
2. 客户端与服务端之间新建了一条UDP隧道，明文传输数据。
3. 设想有误，传输正常。

具体什么情况我需要测试验证

初步测试结束，UDP不通。 附Log

2020/02/03 08:49:02 [Info] v2ray.com/core/app/dispatcher: taking detour [proxy] for [udp:8.8.8.8:53]
2020/02/03 08:49:02 [Info] v2ray.com/core/transport/internet/websocket: creating connection to tcp:xxx.xxx.xxx.xxx:443
2020/02/03 08:49:06 [Info] v2ray.com/core/app/dns: failed to lookup ip for domain google.com at server UDP:8.8.8.8:53 > context deadline exceeded
2020/02/03 08:49:06 [Info] v2ray.com/core/proxy/dns: ip query > v2ray.com/core/app/dns: returning nil for domain google.com > context deadline exceeded
2020/02/03 08:49:06 [Info] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/socks: connection ends > context canceled
2020/02/03 08:49:06 [Info] v2ray.com/core/transport/internet/udp: failed to handle UDP input > io: read/write on closed pipe

1.udp转发正常

你这里大概只测试了从本机到客户端的UDP连接，需要测试的是从客户端到服务端的UDP连接。

对不起，刚才又做了下实验，socks+ws+tls必须开启多线路复用才能实现udp转发，而vmess不需要，具体原因不明。之前说功能上与普通的v2ray+ws+tls没有区别，是我说错了。

[KirbyKFC]

socks+ws+tls必须开启多线路复用才能实现udp转发，而vmess不需要，具体原因不明。

Mux的子连接支持UDP协议，Mux自身通过TCP传输，实现了UDP over TCP所以能走通。至于不开启就无法走通的原因我上面写了。

Mux.Cool 新建子连接

[qiangliu8183]

2位讨论完了？这新姿势到底可行否？

[ghost]

性能问题只有路由器才有，在电脑上几乎没有区别的

[ghost]

性能问题只有路由器才有，在电脑上几乎没有区别的

确实如此，没有百兆以上的宽带和线路，不用路由器或者性能差一点的软路由，又不打游戏，几乎用不出差别。 https://www.youtube.com/watch?v=zlOTrR1AzpA trojan就是仅tls加密，在这么高带宽下，和vmess+ws+tls的区别就这么点，一般情况根本用不出来。 不过计算量的降低还是非常有意义的，在刷固件的路由器上提升应该很明显

[dawnh]

这个看起来很有意思啊。 我又想到了http也可以作为outbound protocol，应该是4.21加入的支持，这个也应该是类似socks2http之类的直接用HTTP 1.1的CONNECT method的实现。 按照你的方案可以protocol用socks，底层streamsetting用ws的话，那岂不是也应该可以protocol用http，底层streamsetting用ws？这样的话可以套任何CDN HTTP代理跑了，而且一般运营商HTTP的qos也比较少。

[daiaji]

这个看起来很有意思啊。 我又想到了http也可以作为outbound protocol，应该是4.21加入的支持，这个也应该是类似socks2http之类的直接用HTTP 1.1的CONNECT method的实现。 按照你的方案可以protocol用socks，底层streamsetting用ws的话，那岂不是也应该可以protocol用http，底层streamsetting用ws？这样的话可以套任何CDN HTTP代理跑了，而且一般运营商HTTP的qos也比较少。

套cdn https？ 不错是不错，反正二次加密本身就很蛋疼，也不太存在大墙解密tls的情况

[diligentpig]

谢谢楼主分享。个人测试，将原来的vmess+ws+tls改成socks+ws+tls之后，速度确实有不小的提升，接近最早单用vmess协议的速度👍

[okudayukiko]

亲测在使用TLS（用大厂证书，不要用自签名证书，也就是"allowInsecure": false）的情况下，可以关闭VMess的加密。

[ghost]

在使用TLS的情况下，可以关闭VMess的加密。

cpu占用那张对比截图里，vmess加密用的是none，alertid为0

[vickunwu]

@kirin10000 请问如果底层传输协议使用TCP，能否使用caddy代理的TLS1.3？这样似乎与Trojan的模式更为相似 在V2ray官方手册中指出，使用TCP连接的效率比WS更高，只是不能套CDN而已

[wonpn]

在openwrt上测了一下，cpu:MT7621AT vmess（不加密） + ws + tls 对比 socks + ws + tls 差别并不大。带宽30M都可以跑满（我也没更好的梯子测），cpu 负载基本持平。 vmess如果加密的话，也就勉强能跑到20M左右，差别还挺大，这cpu太渣了，跑v2ray确实有点吃力，必须dnsmasq分流，流量都走v2ray的话（无论走代理还是直连），负载分分钟占满。

[alexyangjie]

今天在一台vps上测的

bare 2694 MB/s vmess (chacha20-poly1305) 310 MB/s vmess (aes-128-gcm) 330 MB/s vmess (none with tls) 173 MB/s socks5 (tls) 189 MB/s shadowsocks (chacha20-poly1305) 204 MB/s

[ghost]

今天在一台vps上测的

bare 2694 MB/s vmess (chacha20-poly1305) 310 MB/s vmess (aes-128-gcm) 330 MB/s vmess (none with tls) 173 MB/s socks5 (tls) 189 MB/s shadowsocks (chacha20-poly1305) 204 MB/s

我想问一下 1.测试的这几个的传输配置是ws+nginx还是tcp 2.bare是怎么连的？是socks5直连吗？

[alexyangjie]

今天在一台vps上测的 bare 2694 MB/s vmess (chacha20-poly1305) 310 MB/s vmess (aes-128-gcm) 330 MB/s vmess (none with tls) 173 MB/s socks5 (tls) 189 MB/s shadowsocks (chacha20-poly1305) 204 MB/s

我想问一下 1.测试的这几个的传输配置是ws+nginx还是tcp 2.bare是怎么连的？是socks5直连吗？

用的是v2ray的测试工具 https://github.com/v2ray/experiments

1. 传输配置都是tcp，我只是想测试vmess和socks协议的比较
2. bare就是loopback自己传自己，参考测试工具的说明

[ghost]

用的是v2ray的测试工具 https://github.com/v2ray/experiments

1. 传输配置都是tcp，我只是想测试vmess和socks协议的比较
2. bare就是loopback自己传自己，参考测试工具的说明

十分感谢

[fbion]

mark

[Kudryavka03]

如果单纯Socks5+TLS而不是Socks5+WS+TLS，可能可以比Trojan更快

[zhj9709]

wss中vmess加密选none，是不是跟trojan差不多了？

[phlinhng]

wss中vmess加密选none，是不是跟trojan差不多了？

TCP+TLS中vmess選none才會差不多

速度關係應該是 trojan > vmess(tcp)+tls > vmess(ws)+tls

[okudayukiko]

wss中vmess加密选none，是不是跟trojan差不多了？

TCP+TLS中vmess選none才會差不多

速度關係應該是 trojan > vmess(tcp)+tls > vmess(ws)+tls

VMess要进行混淆计算，所以在手机上，SOCKS+TLS/SOCKS+WS+TLS/Trojan比VMess+TLS省电得多。

[phlinhng]

wss中vmess加密选none，是不是跟trojan差不多了？

TCP+TLS中vmess選none才會差不多 速度關係應該是 trojan > vmess(tcp)+tls > vmess(ws)+tls

VMess要进行混淆计算，所以在手机上，SOCKS+TLS/SOCKS+WS+TLS/Trojan比VMess+TLS省电得多。

(先说明，以下内容是我的猜测，有错请指教) 基于socks的连接方式比vmess快是肯定的，但是我相信vmess的混淆计算有值得多花一些计算量来换取的价值。如果采用socks+tls，是否会因为每个封包的长度与特征相同(由于缺少混淆)而增加被牆识别进而封杀的可能性？

[okudayukiko]

wss中vmess加密选none，是不是跟trojan差不多了？

TCP+TLS中vmess選none才會差不多 速度關係應該是 trojan > vmess(tcp)+tls > vmess(ws)+tls

VMess要进行混淆计算，所以在手机上，SOCKS+TLS/SOCKS+WS+TLS/Trojan比VMess+TLS省电得多。

(先说明，以下内容是我的猜测，有错请指教) 基于socks的连接方式比vmess快是肯定的，但是我相信vmess的混淆计算有值得多花一些计算量来换取的价值。如果采用socks+tls，是否会因为每个封包的长度与特征相同(由于缺少混淆)而增加被牆识别进而封杀的可能性？

SOCKS+TLS有个缺点，如果访问TLS端口，就可知道这是SOCKS协议。SOCKS+WS+TLS和SOCKS+H2+TLS会比较安全，WS Path和H2 Path相当于连接密码。 另外IE（包括Edge）代理的SOCKS用的是SOCKS4版本，SOCKS4在本地解析DNS，会有隐私方面的问题。V2RayNG用了Privoxy将SOCKS5代理转换为HTTP代理。

[Sanczzg]

这个看起来很有意思啊。 我又想到了http也可以作为outbound protocol，应该是4.21加入的支持，这个也应该是类似socks2http之类的直接用HTTP 1.1的CONNECT method的实现。 按照你的方案可以protocol用socks，底层streamsetting用ws的话，那岂不是也应该可以protocol用http，底层streamsetting用ws？这样的话可以套任何CDN HTTP代理跑了，而且一般运营商HTTP的qos也比较少。

问题来了, 如果你底层streamsetting用的是ws的话过CDN的时候的流量依旧是ws而不是http啊 我也有点兴趣, 你有没有试过protocol http streamsetting ws最后过cdn的时候流量是http还是ws

[NP-Prob]

今天对这种连接方式研究了一下，首先是对配置文件改进了一下。客户端配置文件已经可以在v2rayn和v2rayng上正常使用，并且弄好了udp转发。 服务端：

{
  "inbounds": [
    {
      "port": 41357,
      "listen": "127.0.0.1",
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": false,
        "userLevel": 999
      },
      "streamSettings": {
        "network":"ws",
        "wsSettings": {
          "path":"/e75500"
        }
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",
      "settings": {}
    }
  ]
}

除了6-11行，其他设置与普通的v2ray+ws+tls没有区别，nginx部分的配置也是与普通的v2ray+ws+tls没有区别。 客户端：

{
  "log": {
    "access": "",
    "error": "",
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls"]
      },
      "settings": {
        "auth": "noauth",
        "userLevel": 10,
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "你的域名",
            "level": 10,
            "port": 443
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "wsSettings": {
          "path": "/e75500"          //这里填你的path
        }
      },
      "mux": {
        "enabled": true,
        "concurrency": 8
      }
    }
  ]
}

把域名和path修改一下，就可以正常使用了，导入到v2rayn/v2rayng中即可。

然后是体验方面的实验结果，和普通的v2ray+ws+tls相比，除了上面说的cpu占用率大降，还有就是速度。速度在带宽方面我用不出区别，主要是因为我家网速太慢了，就30mbps，两种方式都能把我家带宽轻松填满。其次就是延迟，这个提升十分显著。如图，在手机上，这个应该是测的真直连延迟，以前最低都要200ms，而现在都在80ms以内，而且我的宽带ping服务器延迟本来就有40-80ms左右，说明协议的计算带来的延迟几乎没有，这对像我一样要打游戏的简直是个福音。

然后就是以此类推，http2，应该也可以用这种方法。

最后就是如果你正在使用cdn，一定要保证cdn是可靠可信的，因为cdn中转的时候是会将你的tls解密的，再重新加密发送到你的客户端。即使是普通的v2ray+ws+tls，如果你在使用cdn，那么cdn应该是可以知道你在使用v2ray的。其次就是如果你用这种方法连接，一定要保证你的域名和path，不能同时让别人知道，一般来说域名是对外公开的，所以path最好复杂一点。

求助，第一次看到这个方法，我直接在已有可用的v2ray+tls+web+nginx的配置文件里修改为了你写的这个配置方式，但是直接连不上了，客户端没有报错，似乎是在一直向外发送数据，但是服务端的access.log文件里完全没有连接的记录，也无法上网，不知道是什么原因？ 是有哪里需要注意的我没注意到么？

[ghost]

求助，第一次看到这个方法，我直接在已有可用的v2ray+tls+web+nginx的配置文件里修改为了你写的这个配置方式，但是直接连不上了，客户端没有报错，似乎是在一直向外发送数据，但是服务端的access.log文件里完全没有连接的记录，也无法上网，不知道是什么原因？ 是有哪里需要注意的我没注意到么？

我能想到要注意的只有这几个： 1.服务端修改完配置文件后要重启v2ray服务才能生效，并检查是否正常运行 2.服务端里的port要和nginx配置里的的port相同 3.服务端的path和客户端的path和nginx的path要相同 4.服务端配置里加上

  "log": {
    "access": "/etc/v2ray/access.log",
    "error": "",
    "loglevel": "warning"
  },

才能看到access.log

[NP-Prob]

1.服务端修改完配置文件后要重启v2ray服务才能生效，并检查是否正常运行 2.服务端里的port要和nginx配置里的的port相同 3.服务端的path和客户端的path和nginx的path要相同 4.服务端配置里加上

你说的我都做了，access log我也添加了 刚才似乎跑通了，这次直接copy了你的配置文件，我之前可能是配置文件哪里没注意写错了 thanks！

[NP-Prob]

求助，第一次看到这个方法，我直接在已有可用的v2ray+tls+web+nginx的配置文件里修改为了你写的这个配置方式，但是直接连不上了，客户端没有报错，似乎是在一直向外发送数据，但是服务端的access.log文件里完全没有连接的记录，也无法上网，不知道是什么原因？ 是有哪里需要注意的我没注意到么？

我能想到要注意的只有这几个： 1.服务端修改完配置文件后要重启v2ray服务才能生效，并检查是否正常运行 2.服务端里的port要和nginx配置里的的port相同 3.服务端的path和客户端的path和nginx的path要相同 4.服务端配置里加上

  "log": {
    "access": "/etc/v2ray/access.log",
    "error": "",
    "loglevel": "warning"
  },

才能看到access.log

我试了一下，直接连接的一台可以正常使用，但另一台用NAT中转的似乎就无法连接上了，不知道是为什么 那台NAT是屏蔽udp的，不知道是否与这个有关？

[ghost]

我试了一下，直接连接的一台可以正常使用，但另一台用NAT中转的似乎就无法连接上了，不知道是为什么 那台NAT是屏蔽udp的，不知道是否与这个有关？

应该和udp没有关系

[NP-Prob]

我试了一下，直接连接的一台可以正常使用，但另一台用NAT中转的似乎就无法连接上了，不知道是为什么 那台NAT是屏蔽udp的，不知道是否与这个有关？

应该和udp没有关系

刚试了一下，我绕开中转的NAT机直连的话，就可以正常连接了，一旦中转就不行，之前用v2ray+tls+ws时是可以走NAT机中转的，不知道是什么问题。

[komushi]

我试了一下，直接连接的一台可以正常使用，但另一台用NAT中转的似乎就无法连接上了，不知道是为什么 那台NAT是屏蔽udp的，不知道是否与这个有关？

应该和udp没有关系

刚试了一下，我绕开中转的NAT机直连的话，就可以正常连接了，一旦中转就不行，之前用v2ray+tls+ws时是可以走NAT机中转的，不知道是什么问题。

你说的是反向代理吗 我也在尝试用这个socks+ws的反向代理的办法，直接连中转portal服务器没事，但是让bridge作为最后的出口就不行

[bilibilistack]

是这个么 https://github.com/veekxt/v2ray-template/blob/master/websocket%2Bsocks%2Bnginx-or-caddy%2Btls/config_server.json

[NP-Prob]

我试了一下，直接连接的一台可以正常使用，但另一台用NAT中转的似乎就无法连接上了，不知道是为什么 那台NAT是屏蔽udp的，不知道是否与这个有关？

应该和udp没有关系

刚试了一下，我绕开中转的NAT机直连的话，就可以正常连接了，一旦中转就不行，之前用v2ray+tls+ws时是可以走NAT机中转的，不知道是什么问题。

你说的是反向代理吗 我也在尝试用这个socks+ws的反向代理的办法，直接连中转portal服务器没事，但是让bridge作为最后的出口就不行

不是，我的意思是我之前vps上用v2ray+tls+ws+nginx因为速度太慢，就再弄了个NAT机做流量转发，这时是可以使用的。 现在只是把v2ray+tls+ws换成了楼主的办法，这时不通过NAT机做流量转发时，是可以使用的，但是一旦做了流量转发，就连不上了。

[ghost]

是这个么 https://github.com/veekxt/v2ray-template/blob/master/websocket%2Bsocks%2Bnginx-or-caddy%2Btls/config_server.json

看来之前已经有人知道了哈哈哈

[mzz2017]

tls+tcp+socks岂不是更快