最简单的SSR多用户脚本

 

之前一直很喜欢Breakwa11的SSR-Manyuser程序,对接着Mysql功能很强大,可是在配置方面难倒了不少小白。而且很多情况下,VPS的内存不足以支持我们流畅的运行LNMP环境。于是本脚本就诞生了。纯粹使用Shell脚本来完成SSR的用户管理,流量监控部分,满足大部分人使用一个小内存(可以是64MB哦)VPS分享SSr的喜悦.

用户、端口密码增加,修改,删除功能。(已完成)
自动添加,删除相关防火墙政策。(已完成)
流量统计,流量限制功能。(已完成)
支持开机自启(已完成)
支持SSR混淆模式(已完成)
一键搭建脚本(已完成)
简单的控制脚本(已完成)


注意事项

为了防止 SSR 程序被滥用来免流,已经禁止各类非正常 Host 以及 ML 有关端口,愿 SSR 能够继续担当为用户打开通往世界的大门的工具~
只支持统计 IPV4 流量
程序路径已写死,只能通过此脚本进行管理.

系统支持

Ubuntu 14.04
Ubuntu 16.10
Debian 7
Debian 8

安装

wget -N --no-check-certificate https://raw.githubusercontent.com/forkgood/SSR-Bash/master/install.sh && bash install.sh

卸载

wget -N --no-check-certificate https://raw.githubusercontent.com/forkgood/SSR-Bash/master/uninstall.sh && bash uninstall.sh

 

from

https://github.com/forkgood/SSR-Bash

https://github.com/logdns/SSR-Bash

 --------------------

https://github.com/4kercc/SSR-Bash-Python

https://github.com/aihoom/SSR-Bash-Python

--------------------

 

ShadowsoksR多用户管理脚本,轻松修改/添加/删除用户。 

SSR-Bash-python

ShadowsocksR多用户管理脚本(基于官方mujson版本)

 介绍

一个Shell脚本,集成SSR多用户管理,流量限制,加密更改等基本操作。是一个基于ShadowsocksR官方的mujson的辅助脚本。

 更新日志

  • 2017-3-8 1.0正式版本

 系统支持

  • Ubuntu 14
  • Ubuntu 16
  • Debian 7
  • Debian 8
  • CentOS 6
  • CentOS 7

 功能

  • 一键开启、关闭SSR服务
  • 添加、删除、修改用户端口和密码
  • 自由限制用户端口流量使用
  • 自动修改防火墙规则
  • 自助修改SSR加密方式、协议、混淆等参数
  • 自动统计,方便查询每个用户端口的流量使用情况
  • 自动安装Libsodium库以支持Chacha20等加密方式

与上一版改进

 
  1. 支持每个端口单独自定义加密方式,混淆,协议。
  2. 暂时支持了部分兼容协议。
  3. 支持CentOS 系列系统。
  4. 每月自动清空流量使用记录。
  5. 分别记录上传流量和下载流量。
  6. 动态管理用户,每一次更改用户不会影响原有用户端口。
  7. 恢复ShadowsocksR所支持的兼容模式。
  8. 增加返回上一级菜单功能。
  9. 支持为每一个端口添加不同协议参数与混淆参数。

 

 缺点

  • 无法删除最后一名用户(官方限制)
  • 未设置开机启动
  • 部分系统上IP地址识别错误,导致SSR链接生成有问题,手动修改即可。

 安装

wget -N --no-check-certificate 
https://raw.githubusercontent.com/FunctionClub/SSR-Bash-Python/master/install.sh && bash install.sh

 卸载

wget -N --no-check-certificate 
https://raw.githubusercontent.com/FunctionClub/SSR-Bash-Python/master/uninstall.sh && bash uninstall.sh 
 

常见问题

问1:是否需要自己先安装SSR服务端?
答1:不需要,脚本默认自带了安装SSR的部分。请使用纯净的系统进行安装。
问2:是否能和Oneinstack一起安装?
答2:原则上是可以的,但是并不建议放在生产环境中使用,建议单独使用一台VPS来扶墙。
问3:为什么无法开启兼容模式?
答3:因为SSR服务端只支持部分协议的兼容设置,所以并非所有的协议插件都能兼容原版。具体列表参考 SSR协议插件稳文档
问4:脚本安装好连接上没有网络?
答4:请确认好您已经正确填写了加密方式、协议和混淆,并且使用最新的SSR客户端而不是SS客户端。
问5:脚本还是无法使用!
答5:如果可以输入 ssr 命令打开功能菜单,请选择 1 服务管理 再选择 4 查看日志。发送给我详细截图以解决问题。
问6:脚本是否支持 UDP 转发?
答6:默认是开启了 UDP转发的,如果无法使用,请检查SSR官方文档修改本地配置,SSR服务端默认安装在 /usr/local/shadowsocksr

用Linux的交互程序Whiptail安装GUInstaller-For-SSR

一个叫Whiptail的交互式Linux程序。而且它是各大Linux发行版自带的一个工具,所以支持度是非常好的。很多人看到这个界面后会想到Ubuntu和Debian的安装程序。

f:id:briteming:20171027144805p:plain

优点

  • 完美解决传统脚本的中文乱码问题。
  • 解决传统脚本中使用Xshell的时候,退格键会出现 ^H的问题。
  • 基于向导式,小白也能轻松看懂。
  • 看起来很高大上。

缺点

  • 不支持开机启动,毕竟是写着玩玩的,没想过要放在生产环境下使用。
  • 出错无法根据日志来排除错误,因为全部写到 /dev/null 里面了,为了保持始终在图形界面。
  • 不支持手机SSH连接。

系统支持

  • Ubuntu 14
  • Ubuntu 16
  • CentOS 6
  • CentOS 7
  • Debian 7
  • Debian 8

安装脚本

wget --no-check-certificate https://raw.githubusercontent.com/hkxiaoyao/GUInstaller-For-SSR/master/install.sh
bash install.sh

最后说两句

这个程序只是写着玩玩练练手,至于更新什么的我不打算做。反正里面的注释都写得非常清楚了,大部分人都是能看懂的.

项目地址:https://github.com/hkxiaoyao/GUInstaller-For-SSR

 

尝试使用IPFS网络来分发V2Ray的安装包

除了 V2Ray 的开发之外,一个非常重要的问题是分发。也就是先有鸡还是先有蛋的问题。用户需要使用 V2Ray 软件来翻墙,但是使用之前要先下载到安装包,而安装包的下载地址,比如 Github Release,通常是被墙的。

V2Ray 的终极目标是提供一个无障碍的翻墙体验,即当你只有一台全新的电脑,包括网络和浏览器,其它什么都没有的时候,你可以使用 V2Ray 来完全翻墙的第一步。

要做到这一点,需要两个条件:

  1. V2Ray 提供了一个免费的服务器,通过自带的配置文件即可连上;
  2. 用户可以自由地下载到 V2Ray 的安装包。

第一个条件已经完成了,V2Ray 的官方服务器已经稳定工作很长一段时间了。现在面临的主要问题是第二个条件。

network

想必大家都已经看到 Telegram 上的公告,我的第一个想法是通过网盘来分发,某网盘号称国际版没有审查,但在我公布下载链接的数小时内,帐号就被封锁,我也只能呵呵了。

想来想去,传统的 HTTP 道路肯定是走不通的,国内的 HTTP 都有审查,国外的都被墙,没有可用的。那么也只能 P2P 了。

目前对于文件分享,P2P 的一个主流方案是 IPFS。和 BT 类似,IPFS 没有中心服务器,你可以连接到其它的 IPFS 节点来下载所指定的文件。文件名(或目录名)就是一个字符串,有了这个字符串,你就可以下载到 V2Ray 的安装包。

当然这个方案有个缺点,也就是你需要先下载 IPFS 的程序,等于把分发的责任转移给了 IPFS。如果将来有一天,没人可以下载到 IPFS 的程序了,那也就没戏了。

所以现在只能期待 IPFS 依然存活,并且有好心人在墙内做种子。🙏🙏🙏🙏

接下来简单介绍一下 IPFS。在 IPFS 中可以发布文件或者文件夹,每个文件和文件夹都有一个唯一标识,在 IPFS 中通过这个标识可以获取这个文件。比如目前最新的 V2Ray 安装包在这里。这个路径是不可变的,也就是说,之后的版本再次传到 IPFS 之后,会有一个新的标识符。为了解决这个每次都变的问题,IPFS 项目中有个叫 IPNS 的工具用来重定向,大概就相当于域名和 IP 的关系。而 V2Ray 的 IPNS 是这个。不知道为什么 IPNS 比 IPFS 慢了很多,大概是种子不够多的原因吧。

在此希望广大翻墙同胞们一起来做种,让下载速度变得更快。做种的方式大约是,在已经配置完 IPFS 之后,运行:

ipfs pin add -r /ipns/QmdtMuAhEUPFX9NQiGhRj2zhS1oEA76SXNDnZRHqivjMwR

我也是刚刚学着使用 IPFS,如果有问题请指正。

在上述的分发渠道中你还可以找到一些主要的 V2Ray 客户端。如果还需要其它的工具,请留言,之后我会加上.

from 

https://steemit.com/cn/@v2ray/ipfs-v2ray

翻墙协议的三要素

介绍了从用户的角度如何理解翻墙工具,这次我们来讨论一下从工程的角度如何理解翻墙协议,每个翻墙协议有什么差别。

首先,我们来设定一个概念:一个代理(翻墙)协议可能具备的三要素。

一、传输:能在 A、B 两个主机之间建立一条安全可靠的通信通道,用于传输数据;
二、协议:对于将要传输的数据,能将这些数据的目的地告知代理服务器;
三、内容:可以对传输的数据进行优化,比如压缩、合并等。

任何一个翻墙协议都具备以上三要素中的几个或全部。

文字可能较难理解,我们来举一个简单的例子:Socks 协议。Socks 只具备协议要素,即告知代理服务器要把数据发送到哪里去,以达到代理的目的。但众所周知单纯的 Socks 不具备翻墙能力,因为它不能建立可靠的通道(即会被墙)。于是就有了 Shadowsocks。Shadowsocks 在 Socks 的基础上增加了传输要素,对数据加了密,使墙无法分析其内容。而 Shadowsocks 不具备内容要素,因为对于客户端的发来的内容,Shadowsocks 不进行任何修改,直接发送给了代理服务器。

在翻墙过程中,我们可能会使用几个协议的组合,比如 Shadowsocks + KcpTun。无论我们怎么组合,所产生的结果,必须包含传输要素和协议要素,才可以进行可靠的翻墙

为什么不能单独使用 KcpTun 来翻墙,因为 KcpTun 只有传输+内容要素。KcpTun 只能建立连接,对内容进行一定的处理,比如加密以及其内置的 mux 模式。但它不能发送数据的实际目的地,导致了一定要再套一个其它协议才可以用于翻墙。

而在 Shadowsocks (传输+协议) + KcpTun (传输+内容) 的场景中,由于两者都有传输要素,重复了,以至于 Shadowsocks 的加密在这个场景中多余。因为 KcpTun 已经有加密了,Shadowsocks 再多加一层也没用。

这也就是 ShadowsocksR 最近的几个协议推荐使用不加密的原因。

ShadowsocksR 本质上是对 Shadowsocks 进行了一层封装,即 Shadowsocks + X。这个 X 包含了对协议要素的扩(单端口多用户多种加密方式),加强了传输要素(伪装和其它的加密方式)。和 Shadowsocks + KcpTun 同理,Shadowsocks 本身的传输要素就显得不那么重要了。

而 Shadowsocks 最近也加强了传输要素,即 obfs plugin。两者在要素这一层面相差无几,这也是为什么很多人不认为 ShadowsocksR 之于 Shadowsocks 有很大改进的原因。

顺便整理一下常用协议所具备的要素,仅供参考:

  • HTTP/1.1: 协议
  • HTTP/2 (不带 TLS): 协议+内容
  • TLS: 传输
  • Shadowsocks: 传输+协议。AEAD 只是强化了传输,并没有添加新的要素。
  • ShadowsocksR: 传输+协议
  • KcpTun: 传输+内容
  • GoProxy: 等价于 HTTP/2 + TLS,即传输+协议+内容
  • VMess (V2Ray): 传输+协议
  • mKCP (V2Ray): 传输
  • WebSocket (V2Ray): 传输
  • Mux (V2Ray): 协议+内容

当然,一个翻墙协议的效率和它具备几个要素没有半点关系。以上这些内容只是帮助大家理解每个翻墙协议的侧重点,哪些组合是有意义的,哪些是没有意义的。一个协议组合首先要有意义,其次才能探讨它的效率.

 

from 

https://steemit.com/cn/@v2ray/unzev

适合自己的才是最好的

最近有很多关于 Shadowsocks 安全性以及各种解决方案的讨论,比如这个这个,还有这个。实际上讨论的范围不仅限于 Shadowsocks,但不可否认它是目前最流行的翻墙工具,所以也是最大的目标。当然了,这类的讨论不会有什么明确的结论,谁都说服不了谁。重要的是大家表达了自己的观点和需求,让旁人也能更好的了解翻墙中可能碰到的各种问题。

于是我也来凑个热闹,说说 V2Ray 的设计理念。

首先,V2Ray 是什么?V2Ray 是一个网络代理工具。什么是代理?代理是当 A 和 B 想说话但不能直接对话时,要找 C 来传话,这时 C 就是代理。那么在这个过程中,C 有哪些职责?很简单,把话传到,把话传对,并且不泄露给除 A、B 之外的人。

看似这个描述很简单,把它应用到代理软件中,可以表述为下面的内容:

  • 开放网络连接,使得 A 和 B 可以间接地进行正常通信;
  • 通信内容不能被第三方知晓;
  • 网络连接要稳定,不能间歇或永久地失效;

之所以没有写成一二三条,是因为上述三条的优先级,在不同的人看来是不一样的。

大多数人的选择应该会是“正常通信”。毕竟翻墙工具诞生的意义就是让用户访问被墙的网站,比如 Google 被墙了,我架设一个 Shadowsocks 服务器就又可以访问 Google 。至于我在 Google 上搜索了什么,都是一些人畜无害的内容,我想别人也没兴趣知道。只要这个工具能让我爽快地访问 Google,它就是一个好工具。这种情况我们称为“速度优先”。

另外一些人可能就比较注重私密性,不管我在搜索一些什么内容,可能也就是一些网红八卦,但我就是不想让别人知道,被别人知道了我就不爽。这种情况我们称为“隐私优先”。

还有一些人对服务器的稳定性有需求,平时我不怎么翻墙,而一旦需要的时候,就一定要可以及时翻出去。几百万的大单,谈不成这个月就要喝西北风了。这些人对翻墙服务(或服务器)的稳定性要求很高,服务不能断线。而断线的情况有很多种,比如翻墙协议被识别了,或者服务器被探测了,都可以造成翻墙服务失效。这种情况我们称为“稳定优先”。

上述的三种情况在翻墙工具中都有相应的功能,比如“速度优先”可能的问题是 ISP 的 QoS 限制,应对方式是流量混淆。又比如“隐私优先”可能需要工具提供完美的加密方式。而“稳定优先”需要翻墙服务器不被探测,翻墙协议需要减少特征。正是由于这些纷繁复杂的功能,引起了大量的讨论。观众不明就里,而开发人员则忙于推销自己的产品。有些问题呢,就越讨论越看不懂了。

从 V2Ray 的角度来看,这是一个不可调和的矛盾。每个人的需求不同,适合自己的才是最好的。不能因为开发人员觉得一项功能好,就强加给用户。用户用着没效果,也不会感谢开发者。

举个例子,Shadowsocks 最近的一次协议升级,使用 AEAD 算法取代了 OTA,提供了更好的加密特性。这个升级在“速度优先”的用户看来是完全没有意义的。因为 AEAD 只是加强了数据完整性,对于 QoS 和可被探测性没有任何改进。也就是说,在客观环境不变的情况下,升级到 AEAD 不会在翻墙速度上有任何提升。于是很多人就会问,到底要不要升级 AEAD,升完对我有什么好处。由于惰性,在没有明显优势的情况下,AEAD 的推广有着很大的阻力。

V2Ray 则尝试从另一个角度来解决这样的问题:提供很多功能,让用户根据自己的需求自由组合。虽然各种组合并不一定能满足所有人的需求,但总比只有一个选择来得好。

对于上述的三个需求,V2Ray 分别提供了不同的特性:

  • 速度优先:VMess 协议、mKCP 协议、Mux.Cool 协议,内部路由分流
  • 隐私优先:TLS (完整实现,非伪装)
  • 稳定优先:HTTP 伪装、BT 伪装等,以及 Mux.Cool 协议。

V2Ray 在设计时已考虑到多个功能相互组合的使用,比如你可以使用 VMess + TLS 来达到隐私和速度的双重保证,或者使用 VMess + Mux 来提升速度和稳定性。也考虑到不同的用户的需求不同,V2Ray 的所有功能都可以选择打开或关闭,不会把任何一个功能强加给用户。不同的配置可以达到不同的效果,而在 V2Ray 中,你只需要一个配置文件就可以应对这些不同的需求。

当然 V2Ray 的功能远不止上述这些,如果你现在的翻墙工具已不能满足你的日常需求,何不试一下新的轮子呢?

from 

https://steemit.com/cn/@v2ray/47wumq

V2ray的性能测试

一直都有人问 V2Ray 的性能问题,一直都很无奈因为没有人测过。被问得烦了,现在给一个比较科学,比较准确的结论。

本次测试的目的

测试 VMess 和 Shadowsocks 各种加密方式,在传输过程中的极限速度。

测试方法

在同一台主机上同时启动 V2Ray 客户端和服务器端,使用环回网络(Loopback)进行网络传输。客户端会接受到预设数量的数据,然后验证服务器端发出同样数量的数据。

测试环境

一台云主机,内存 2GB,CPU 信息如下。显然这台机器本身的性能不怎么样,如果用一台更好的机器,会得到更好的绝对数值,但本次实验结果的数值比例有参考价值。

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                2
On-line CPU(s) list:   0,1
Thread(s) per core:    1
Core(s) per socket:    2
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 61
Model name:            Virtual CPU a7769a6388d5
Stepping:              2
CPU MHz:               2399.996
BogoMIPS:              4799.99
Hypervisor vendor:     KVM
Virtualization type:   full
L1d cache:             32K
L1i cache:             32K
L2 cache:              4096K
NUMA node0 CPU(s):     0,1

测试工具

特地写了两个小工具:loadgen 和 receiver。

loadgen 用于发送数据,它可以对某个端口建立连接,支持直连和 Socks 协议。可配置并发一定数量的连接,发送指定数量的数据后,验证 receiver 的反馈。如果 receiver 收到了同样数量的数据,则表明传输结束。

receiver 用于接收数据,对于每个连接,每次收到数据后,把总共收到的数据字节数发回,并等待连接发起方关闭连接。

由于 VMess 的正确性已被其它的测试验证,这里只需要验证连接畅通,即收到数据量等于发出数据量即可。

基本信息

我们用 loadgen 和 receiver 直接对接,可以得出环回网络的大致性能。实验结果如下:

数据量:50 GB / 连接

并发连接数 1 2 4
速度(MB/s) 4266 4654 4551

对比下面实验中的速度,可以认为环回网络的基本速度不会成为瓶颈。

进一步的基础信息,我们又测了一下使用 V2Ray 直连的速度。实验中只启动一个 V2Ray 进程,配置 Dokodemo-door <-> Freedom。实验结果如下:

数据量:10 GB / 连接

并发连接数 1 2 4
速度(MB/s) 640 819 787

VMess 测试

测试场景的差别是 VMess 的加密方式,其它都一样。传入依然是 Dokodemo-door,传出是 Freedom。

  • VMess CFB: AES-128-CFB 加密方式
  • VMess GCM: AES-128-GCM 加密方式
  • VMess Chacha: Chacha20-poly1305 加密方式
  • VMess None: 不加密

结果如下(数据量:10 GB / 连接):

解读如下:

  • 速度 GCM > Chacha > None > CFB;
  • VMess 可以同时处理多个连接。由于 CPU 是双核,所以 2 个连接的速度比单个连接快,而 4 个连接对比 2 个连接则没有明显提升;

很有趣的一点是 None 居然比 GCM 慢。不加密反而比加密慢,有一点违反常识。原因是这样的:VMess 不管加不加密,都会进行数据校验,None 中使用的校验算法是 FNV,而 GCM 是一个 AEAD 算法,自带校验。于是带 CPU 加成的校验比软件实现的校验快了不小。这一点也超出了开发人员的预期,之后会考虑提升校验的性能。

与 Shadowsocks 对比

V2Ray 和 Shadowsocks 的比较也是一个常见问题。既然我们有了一个性能测试的工具,那就一起测一下吧。

  • V2Ray SS CFB: V2Ray 中的 Shadowsocks 实现,AES-128-CFB 加密方式;
  • SS-Libev CFB: Shadowsocks libev 2.5.6,AES-128-CFB 加密方式,客户端 ss-tunnel,服务器端 ss-server;
  • SSR-PY CFB: ShadowsocksR 最新的代码(2017-01-20),AES-128-CFB 加密方式。其它的参数都是默认的:auth_aes128_md5、tls1.2_ticket_auth_compatible。

OTA 在所有 Shadowsocks 中都启用了。

实验结果(数据量:10 GB / 连接):

解读如下:

  • VMess 的速度优于 Shadowsocks;
  • 比起 ss-libev 和 ssr-python,V2Ray 在多并发连接的场景中更有优势;

结论

  • 在一台双核 2.4 GHz 的主机上,V2Ray 的极限传输速度超过 400 MB/s。
  • 如果你对速度有需求,请使用 VMess + AES-128-GCM。

后记

  • 在日常使用中,传输速度一般都不会超过 10 MB/s,上述测试的每种方式都可以满足需求。但如果你需要高性能传输,可以按测试结果选择合适的方式。
  • 上述的测试结果都是运行多次的平均值。由于虚拟机的不稳定性,误差在 5% 以下。
  • 其它方面的测试,如 CPU 和内存占用,会在后续的测试中进行。
  • loadgen 和 receiver 可以由 iPerf 替代,唯一的问题是 iPerf 不支持 Socks 协议。
  • 上述所有工具和测试脚本的源代码可以在这里找到

from https://steemit.com/cn/@v2ray/3cjiux

V2Ray的官方一键安装脚本,我测试成功,成功用此脚本翻墙

 

并不要求v2ray的本地版本号和服务器上的版本号一致,我的情况:我的本地版本号是2.41,而服务器上的版本号是2.40 。另外要特别注意的是:本地机器的时间要跟北京时间一致!!误差不能超过2分钟,否则会翻墙失败!!
这个脚本可以在Debian系列或者支持SystemdLinux操作系统使用。比如说,Centos 6.xdebian系也不带有 Systemd,因此在CentOS 6.x不可使用官方提供的脚本安装V2Ray,但是CentOS 7.x内置有Systemd的所以可以使用脚本安装;Ubuntu 14.04虽然没有Systemd,但属于Debian系列,同样可以使用这个脚本。
现在市面上绝大多数Linux发行版的最新版本都内置了Systemd,在支持Systemd的系统中,V2Ray的安装脚本会添加一个 Systemd的单元文件可以使得开机后自动运行软件,以及当V2Ray意外停止运行时自动启动V2Ray(应该类似于 supervisord托管服务),推荐用户使用带Systemd的系统。
Github地址:https://github.com/v2ray/v2ray-core
系统环境:本教程测试系统为Ubuntu 16.04 x64

官方的安装方法:

登陆vps,运行下面命令:
wget https://raw.githubusercontent.com/v2ray/v2ray-core/master/release/install-release.sh
bash install-release.sh
主程序为/usr/bin/v2ray/v2ray,配置文件为 /etc/v2ray/config.json。不过这个配置文件config.json不太好用。可访问https://htfy96.github.io/v2ray-config-gen/ ,来生成v2ray的配置文件。
 我用https://htfy96.github.io/v2ray-config-gen/ 生成的v2ray的配置文件翻墙成功。
 https://htfy96.github.io/v2ray-config-gen/ ,v2ray的配置文件生成器,很不错。值得一试.
 
注:最好用chrome+switchyomega来翻墙,这样翻墙的速度才快。
 
真实的服务端的配置文件的内容:
{
"log": {
"access": "/var/log/v2ray/access.log",
"error": "/var/log/v2ray/error.log",
"loglevel": "warning"
},
"inbound": {
"port": 12345,
"protocol": "vmess",
"settings": {
"clients": [
{
"id": "f2707fb2-70fa-6b38-c9b2-81d6f1efa323",
"level": 1,
"alterId": 100
}
]
},
"streamSettings": {
"network": "kcp"
},
"detour": {
"to": "vmess-detour-746765"
}
},
"outbound": {
"protocol": "freedom",
"settings": {}
},
"inboundDetour": [
{
"protocol": "vmess",
"port": "10000-10010",
"tag": "vmess-detour-746765",
"settings": {},
"allocate": {
"strategy": "random",
"concurrency": 5,
"refresh": 5
},
"streamSettings": {
"network": "kcp"
}
}
],
"outboundDetour": [
{
"protocol": "blackhole",
"settings": {},
"tag": "blocked"
}
],
"routing": {
"strategy": "rules",
"settings": {
"rules": [
{
"type": "field",
"ip": [
"0.0.0.0/8",
"10.0.0.0/8",
"100.64.0.0/10",
"127.0.0.0/8",
"169.254.0.0/16",
"172.16.0.0/12",
"192.0.0.0/24",
"192.0.2.0/24",
"192.168.0.0/16",
"198.18.0.0/15",
"198.51.100.0/24",
"203.0.113.0/24",
"::1/128",
"fc00::/7",
"fe80::/10"
],
"outboundTag": "blocked"
}
]
}
}
}
 
真实的客户端的配置文件的内容:
{
"log": {
"loglevel": "warning"
},
"inbound": {
"listen": "127.0.0.1",
"port": 3080,
"protocol": "socks",
"settings": {
"auth": "noauth",
"udp": true,
"ip": "127.0.0.1"
}
},
"outbound": {
"protocol": "vmess",
"settings": {
"vnext": [
{
"address": "my_vps_ip",
"port": 12345,
"users": [
{
"id": "f2707fb2-70fa-6b38-c9b2-81d6f1efa323",
"level": 1,
"alterId": 100
}
]
}
]
},
"streamSettings": {
"network": "kcp"
}
},
"outboundDetour": [
{
"protocol": "freedom",
"settings": {},
"tag": "direct"
}
],
"routing": {
"strategy": "rules",
"settings": {
"rules": [
{
"type": "field",
"port": "54-79",
"outboundTag": "direct"
},
{
"type": "field",
"port": "81-442",
"outboundTag": "direct"
},
{
"type": "field",
"port": "444-65535",
"outboundTag": "direct"
},
{
"type": "field",
"domain": [
"gc.kis.scr.kaspersky-labs.com"
],
"outboundTag": "direct"
},
{
"type": "chinasites",
"outboundTag": "direct"
},
{
"type": "field",
"ip": [
"0.0.0.0/8",
"10.0.0.0/8",
"100.64.0.0/10",
"127.0.0.0/8",
"169.254.0.0/16",
"172.16.0.0/12",
"192.0.0.0/24",
"192.0.2.0/24",
"192.168.0.0/16",
"198.18.0.0/15",
"198.51.100.0/24",
"203.0.113.0/24",
"::1/128",
"fc00::/7",
"fe80::/10"
],
"outboundTag": "direct"
},
{
"type": "chinaip",
"outboundTag": "direct"
}
]
}
}
}
------------------------------
 
网上的一对配置文件(我没试过这对配置文件)
 
服务器端的配置文件内容:
{
  "log": {
    "access": "/var/log/v2ray/access.log",
    "error": "/var/log/v2ray/error.log",
    "loglevel": "warning"
  },
  "inbound": {
    "port": 1111,
    "protocol": "vmess",
    "settings": {
      "clients": [
        {
          "id": "UUID1",
          "level": 1,
          "alterId": 64
        },
        {
          "id": "UUID2",
          "level": 1,
          "alterId": 64
        }
      ],
      "detour": {
         "to": "detour-kcp"
      }
    },
    "streamSettings": {
      "network": "kcp"
    }
  },
  "inboundDetour": [
    {
      "protocol": "shadowsocks",
      "port": 20001,
      "settings": {
        "method": "aes-256-cfb",
        "password": "key1",
        "udp": true
      }
    },
    {
      "port": 20002,
      "protocol": "vmess",
      "settings": {
        "clients": [
          {
            "id": "UUID3",
            "level": 1,
            "alterId": 64
          }
        ]
      }
    },
    {
      "port": 21003,
      "protocol": "vmess",
      "settings": {
        "clients": [
          {
            "id": "UUID4",
            "level": 1,
            "alterId": 64
          }
        ],
        "detour": {
          "to": "detour-kcp"
        }
      },
      "streamSettings": {
        "network": "kcp"
      }
    },
    {
      "port": 22004,
      "protocol": "vmess",
      "settings": {
        "clients": [
          {
            "id": "UUID5",
            "level": 1,
            "alterId": 64
          }
        ],
        "detour": {
          "to": "detour-tcp"
        }
      } 
    },
    {
      "protocol": "vmess",
      "port": "50001-50100",
      "tag": "detour-kcp",
      "settings": {},
      "allocate": {
        "strategy": "random",
        "concurrency": 3,
        "refresh": 360
      },
      "streamSettings": {
        "network": "kcp"
      }
    },
    {
      "protocol": "vmess",
      "port": "51001-51100", 
      "tag": "detour-tcp",
      "settings": {},
      "allocate": {
        "strategy": "random",
        "concurrency": 3,
        "refresh": 360
      }
    }
  ],
  "outbound": {
    "protocol": "freedom",
    "settings": {}
  },
  "outboundDetour": [
    {
      "protocol": "blackhole",
      "settings": {},
      "tag": "blocked"
    }
  ],
  "routing": {
    "strategy": "rules",
    "settings": {
      "rules": [
        {
          "type": "field",
          "ip": [
            "0.0.0.0/8",
            "10.0.0.0/8",
            "100.64.0.0/10",
            "127.0.0.0/8",
            "169.254.0.0/16",
            "172.16.0.0/12",
            "192.0.0.0/24",
            "192.0.2.0/24",
            "192.168.0.0/16",
            "198.18.0.0/15",
            "198.51.100.0/24",
            "203.0.113.0/24",
            "::1/128",
            "fc00::/7",
            "fe80::/10"
          ],
          "outboundTag": "blocked"
        }
      ]
    }
  }
}

客户端的配置文件的内容:
{
  "log": {
    "loglevel": "warning"
  },
  "inbound": {
    "port": 1081,
    "listen": "127.0.1.1",
    "protocol": "socks",
    "settings": {
      "auth": "noauth",
      "udp": true,
      "ip": "127.0.1.1"
    }
  },
  "outbound": {
    "protocol": "vmess",
    "settings": {
      "vnext": [
        {
          "address": "vpsip",
          "port": 1111,
          "users": [
            {
              "id": "uuid1",
              "alterId": 64,
              "security": "auto"
            }
          ]
        }
      ]
    },
    "streamSettings":{
      "network":"kcp"
    },
    "mux": {
      "enabled": true
    }
  },
  "inbounddetour": [
    {
          "port": 1082,
    "listen": "127.0.2.1",
    "protocol": "http",
    "settings": {
      "timeout": 0
    } 
    }
  ],
  "outboundDetour": [
    {
      "protocol": "freedom",
      "settings": {},
      "tag": "direct"
    }
  ],
  "dns": {
    "servers": [
      "8.8.8.8",
      "8.8.4.4",
      "localhost"
    ]
  },
  "routing": {
    "strategy": "rules",
    "settings": {
      "domainStrategy": "IPIfNonMatch",
      "rules": [
        {
          "type": "field",
          "port": "1-52",
          "outboundTag": "direct"
        },
        {
          "type": "field",
          "port": "54-79",
          "outboundTag": "direct"
        },
        {
          "type": "field",
          "port": "81-442",
          "outboundTag": "direct"
        },
        {
          "type": "field",
          "port": "444-65535",
          "outboundTag": "direct"
        },
        {
          "type": "chinasites",
          "outboundTag": "direct"
        },
        {
          "type": "field",
          "ip": [
            "0.0.0.0/8",
            "10.0.0.0/8",
            "100.64.0.0/10",
            "127.0.0.0/8",
            "169.254.0.0/16",
            "172.16.0.0/12",
            "192.0.0.0/24",
            "192.0.2.0/24",
            "192.168.0.0/16",
            "198.18.0.0/15",
            "198.51.100.0/24",
            "203.0.113.0/24",
            "::1/128",
            "fc00::/7",
            "fe80::/10"
          ],
          "outboundTag": "direct"
        },
        {
          "type": "chinaip",
          "outboundTag": "direct"
        }
      ]
    }
  }
}

注意客户端和服务端配置文件中的服务器地址address,端口portalterIdid等保持一致。

配置文件说明:
服务端:

  1. 我的这个配置文件,服务短配置的主入口:kcp+vemss
  2. 因为手机软件不支持kcp加速,又设了2个不使用kcpvemss入口。
  3. 备用设立了一个SS入口。
  4. 同时设置了动态端口,主入口支持动态端口,其中一个vemss的支持动态端口。

客户端:

  1. 考虑到部分电脑软件只支持http协议,本地监测的端口有sockshttp这俩。
  2. 127.0.1.1+1081是socks
  3. 127.0.2.1+1082是http

使用方法:
修改协议后然后运行V2ray,打开本地浏览器代理服务器设置,设置代理为SOCKS代理或者http代理,代理服务器地址:127.0.1/2.1,代理端口为1081/1082。

----------

http://www.jianshu.com/p/b59150fd8f47

http://archive.is/r4HPI

----------