v2ray配置文件-说明

发表于 阅读次数： 本文字数： 2.4k 阅读时长 ≈ 9 分钟

v2ray配置文件

config基本配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

{

  "log": {},          #日志文件路径

  "api": {},          #api路径配置

  "dns": {},          #dns配置

  "stats": {},          #如果有开启全局统计会出现在这

  "routing": {},          #路由配置用来多个跨服务器商议

  "policy": {}          #政策，定义等级，可以分等级给配置

  "reverse": {},          #全局统计开关

  "inbounds": []          #进站配置

  "outbounds": [],          #出战配置

  "transport": {          #底层传输配置，全局设置

}

协议

V2Ray 支持以下协议：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

Blackhole           #出战专用，黑洞，可以达到禁止访问某些网站的效果

Dokodemo-door           #Dokodemo door           #（任意门）是一个入站数据协议，它可以监听一个本地端口，并把所有进入此端口的数据发送至指定服务器的一个端口，从而达到端口映射的效果

Freedom           # Freedom 是一个出站协议，可以用来向任意网络发送（正常的） TCP 或 UDP 数据。

HTTP          #出入站协议，模仿http

MTProto           #MTProto 是一个 Telegram 专用的代理协议，不建议使用

Shadowsocks           #Shadowsocks 协议，包含入站和出站两部分，兼容大部分其它版本的实现。老牌经典但是风险高

Socks           # 标准 Socks 协议实现，兼容 Socks 4、Socks 4a 和 Socks 5。容易被查

VMess           # VMess 是一个加密传输协议

除开那些用来阻止访问，特殊的转或者监听端口的，剩下的可以用的协议就是VMess，Shadowsocks，Socks，HTTP四个个协议。

如果是新版还有vless,trojan这两个。我们主要用VMess，Shadowsocks之前被爆出过有漏洞，可以准确的被GFW侦测到，确实之前我服务器也因此被封，最新的2022的Shadowsocks已经改善和解决了这个问题。

20230328144407

但是这个需要使用Xray才可以支持。

协议的配置既可以在"transport"，也可以在"inbounds"下进行单独的配置。如果在在前者，那么就是全局配置，如果是后者，可以针对不同用户进行配置。但是全局传输方式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

{

  "port": 1080,           #监听的端口

  "listen": "127.0.0.1",          #监听的地址，如果在docker内网可以修改为docker的地址

  "protocol": "协议名称",           #使用协议列表内入站的协议

  "settings": {},           # 具体的配置内容，视协议不同而不同。详见每个协议中的InboundConfigurationObject。

  "streamSettings": {},           # 这个就是之前说的"transport"在不同协议下的配置，实现一个协议下多个传输配置

  "tag": "标识",          # 就是拿来标记的

  "sniffing": {           # 尝试探测流量的类型，用来探测流量类型，然后

    "enabled": false,           #开关

    "destOverride": ["http", "tls"]           #当流量为指定类型时，按其中包括的目标地址重置当前连接的目标。

  },

  "allocate": {       #端口分配策略。"always"表示总是分配所有已指定的端口，port中指定了多少个端口，V2Ray 就会监听这些端口。"random"表示随机开放端口，每隔refresh分钟在port范围中随机选取concurrency个端口来监听。

    "strategy": "always",

    "refresh": 5,       #随机端口刷新间隔，单位为分钟。最小值为2，建议值为5。这个属性仅当strategy = random时有效。

    "concurrency": 3      #随机端口数量。最小值为1，最大值为port范围的三分之一。建议值为3。

  }

}

传输方式

这"streamSettings"下配置传输方式，一般而言，使用vmess协议，当然如果你是使用Shadowsocks软件可以是用用对应的协议。

接下来就传输方式，即你们经常见到的Websocket，Tcp，这些配置，这些决定了传输的速度，如果你对速度有要求，可以在这些方面上进行配置，已知的配置种类有：

1
2
3
4
5
6
7
8
9
10
11
12
13

TCP 

mKCP

WebSocket

HTTP/2

DomainSocket

QUIC

TCP传输方式

HTTP伪装：如果你没有增加TLS，即你没有为你的域名增加SSL证书的话，就是HTTP伪装，将你和服务器的流量伪装成网站流量，但是由于没有加密证书，所以不安全，大家也不推荐。

TLS:而TLS则需要你有一个域名，然后将你和服务器的流量伪装成一个正规网站的访问，安全性很高，而且不怕被检测，但是需要你申请ssl证书配置和路径，还需要打开tls。

TCP+TLS+其他：这种的就是，我v2ray使用tcp配置，但是不主动访问我得端口，前面访问一个正经的网站服务，可以得到回应，而且还能访问，只有在特殊路径或者特定情况下，前面的web服务器才会将流量转发过来，前端web服务器可以使用nginx，caddy，appache，如果不需要web服务器的话，直接来个TLS分流器也是可以的。这是一种可以跟web服务器共存的方式。

mKCP传输方式

V2Ray 引入了 KCP 传输协议，并且做了一些不同的优化，称为 mKCP。如果你发现你的网络环境丢包严重，可以考虑一下使用 mKCP。由于快速重传的机制，相对于常规的 TCP 来说，mKCP 在高丢包率的网络下具有更大的优势，也正是因为此， mKCP 明显会比 TCP 耗费更多的流量，所以请酌情使用。要了解的一点是，mKCP 与 KCPTUN 同样是 KCP 协议，但两者并不兼容。

这个就是经常说的KCP。

DomainSocket传输方式

Domain Socket 使用标准的 Unix domain socket 来传输数据。它的优势是使用了操作系统内建的传输通道，而不会占用网络缓存。相比起本地环回网络（local loopback）来说，Domain socket 速度略快一些。所以如果TCP+TLS+其他，其中TLS和web服务器都处理好了数据，剩下的就是系统内部端口的转发，这时候可以考虑使用DomainSocket，速度会更快，尤其速度超过 50Mbps 时，通常会有较明显的性能差距。但是需要注意 如果指定了 domain socket 作为传输方式，在入站出站代理中配置的端口和 IP 地址将会失效，所有的传输由 domain socket 取代。毕竟内部传输不需要ip地址和监听这些的。

WebSocket传输方式

WebSocket是一种网络传输协议，可在单个TCP连接上进行全双工通信，位于OSI模型的应用层。而之前大火的WebSocket+TLS+CDN，就是三者的互相连接，我v2ray用WebSocket，然后用web服务器申请SSL证书，然后再套上一个CDN。其实没有什么难的，主要是涉及三个环节，所以大家会比较复杂，这种的类似TCP+TLS+其他，安全性是一样的，在网络上都是属于探查不到的，毕竟有CDN掩护，可以救那些被封锁的IP，其他倒是没有什么作用。

HTTP/2传输方式

简单地说 HTTP/2 是 HTTP/1.1 的升级版（目前大多数网页还是 HTTP/1.1）。其中HTTP/2+TLS+WEB， H2流量理论上跟 ws 一样可以被 CDN 转发。 但是遗憾的是, Cloudflare 只支持与源服务器进行 HTTP/1.x 通信。

QUIC 传输方式

QUIC 全称 Quick UDP Internet Connection，是由 Google 提出的使用 UDP 进行多路并发传输的协议。其主要优势是:

  1. 减少了握手的延迟（1-RTT 或 0-RTT）

  2. 多路复用，并且没有 TCP 的阻塞问题

  3. 连接迁移，（主要是在客户端）当由 Wifi 转移到 4G 时，连接不会被断开。

QUIC 目前处于实验期，使用了正在标准化过程中的 IETF 实现，不能保证与最终版本的兼容性。

最后来说说CDN：

目前和 V2Ray 兼容的 CDN 国外有 Cloudflare，国内阿里云和腾讯云，这三家的 CDN 是支持 WebSocket 的。剩下的几家不支持 WebSocket，也不会 keep TCP connection。因此 HTTP/2 回源也不支持（访问支持 HTTP/2 和回源支持 HTTP/2 是两回事）。 另外，使用国内 CDN 需要域名备案并服务商实名认证。使用有风险，入坑需谨慎。

所以这也是为什么必须使用WebSocket+TLS+CDN才会大火，毕竟他在拯救被墙IP上无所替代。根据最新的Cloudflare文档，应该是支持HTTP/2回源的,但是还不支持多路复用。

20230327124619

至于CDN加速问题，这个见仁见智，毕竟它对我的最大作用在于解封IP，加速反正我是没感觉到，因为CDN是边缘算法，但是并不是每次都能找到你最近的一个服务群。

总结：

说了这么多，现在来总结一下:

如果IP被墙：那么只有套CDN一条路子：WebSocket+TLS+CDN

如果IP是正常的，那么建议HTTP/2+TLS或者TCP+TLS，没必要在前面套上一个CDN。

至于最近大火的Xray，相较于v2ray，它更加简便，没必要再tls加密之下，再加密一层，也可以增加响应速度。但是如果你的服务器像我一样，还有其他服务的话，那么不是很建议你更换，xray创新的xtls协议，需要接管全部端口，按照正常的话是web服务器分流，然后转发给xray。但是xray完全接管了服务器，把所有流量排查了之后，再转给后端的web服务器，让他去处理，所以如果你有在服务器上搭建网站，那么就会出现这个问题。