ShadowsocksR 协议插件文档

概述

本插件旨在简化不同协议接口的生成。其实现方式是在原有协议上增加编码和解码接口，不仅能伪装成其他协议流量，还能将原协议转换为其他协议以实现兼容或优化（目前接口功能仍在完善和测试中），要求服务端与客户端使用相同的协议插件。插件分为两大类：混淆插件和协议定义插件。

插件分类介绍

1. 混淆插件

此类插件用于定义加密后的通信协议，主要用于协议伪装，部分插件兼容原协议。

plain：表示不进行混淆，直接使用协议加密后的数据包进行发送。

http_simple：不完全遵循HTTP/1.1标准，仅进行头部的GET请求和简单回应，后续为原协议流。使用此混淆后，部分地区已观察到其对QoS的欺骗性。此混淆的特征明显，可能面临封锁风险。该插件兼容原协议（需在服务端配置为http_simple_compatible），延迟与原协议几乎无异。客户端可自定义参数，指定HTTP请求的host，例如设置为cloudfront.com伪装为云服务器请求，可用逗号分隔多个host（如a.com,b.net,c.org），将随机选择。错误设置可能导致连接断开或IP被封锁，若不确定如何设置，请留空。服务端也支持自定义参数，作为客户端填写参数的列表，使用逗号分隔。

高级设置（C#版、Python版及ssr-libev版均支持）：可自定义几乎完整的HTTP头，从第三行开始的内容可自由配置，例子：baidu.com#User-Agent: abcnAccept: text/htmlnConnection: keep-alive。#号前为host，后为自定义header，换行用n表示（在配置文件中可直接写n），如需单独的号，可写为，末尾无需写n，程序自动添加两个换行。

http_post：与http_simple基本相同，区别在于采用POST方式发送数据，更符合HTTP规范，欺骗性更佳，但POST请求行为可能被统计分析识别异常。此插件兼容http_simple，同时也兼容原协议（需在服务端配置为http_post_compatible），参数设置等内容请参见http_simple，使用自定义HTTP头时，务必填写boundary。

random_head（不建议使用）：在通信前发送一个几乎随机的数据包（目前末尾4字节为CRC32），目标是使首个数据包没有有效信息，干扰统计学习机制。此插件兼容原协议（需在服务端配置为random_head_compatible），增加了一次握手，连接时间稍长，握手过程后无冗余数据包，不支持自定义参数。

tls1.2_ticket_auth（强烈推荐）：模拟TLS1.2协议下的握手，具备session ticket。该插件完美伪装为TLS1.2，因有ticket而省略复杂的证书步骤，防火墙无法基于证书判断。同时具备一定的抗重放攻击能力和包长度混淆能力。若遇重放攻击，服务端日志中会记录，可通过grep "replay attack"检索。此插件可兼容原协议（需在服务端配置为tls1.2_ticket_auth_compatible），连接时间稍长，使用C#客户端时自动重连表现优于其他插件。客户端支持自定义参数，参数为SNI，即发送host名称字段，可伪装为云服务器请求，推荐设置为cloudflare.com或cloudfront.net。服务端目前不支持自定义参数。

2. 协议定义插件

此类插件用于定义加密前的协议，主要用于增强安全性和隐蔽性，部分插件兼容原协议。

origin：使用原始SS协议，速度最快，适合限制少或审查宽松的环境，不建议在严格环境下使用。

verify_deflate（不建议）：对每个包进行deflate压缩，数据格式为：包长度(2字节)|压缩数据流|原数据流Adler-32。此格式省略了0x78,0x9C两字节头部。对已压缩或加密的数据，压缩效果较差（可能增加1~20字节），未加密的HTML文本压缩效果良好。由于压缩和解压缩占用CPU资源，不建议多用户同时使用。此插件不能兼容原协议，请勿添加_compatible后缀。

verify_sha1（已废弃）：对每个包进行SHA-1校验，具体协议描述见One Time Auth，握手数据包增加10字节，其余数据包增加12字节。此插件能兼容原协议（需在服务端配置为verify_sha1_compatible）。

auth_sha1（已废弃）：对首个包进行SHA-1校验，发送随机客户端id(4byte)、连接id(4byte)、unix时间戳(4byte)，后续使用Adler-32作为校验码。此插件可抵抗一般重放攻击，默认同一端口支持64个客户端，可修改限制数量，服务器与客户端UTC时间差不超过1小时，通常只需客户端校准本地时间及时区。此插件与原协议握手延迟相同，兼容原协议（需在服务端配置为auth_sha1_compatible），支持服务端自定义参数，参数为最大客户端数量的10进制整数。

auth_sha1_v2（已废弃）：与auth_sha1类似，取消时间验证，避免因时间问题导致无法连接，客户端ID增至8字节，长度混淆更大。兼容原协议（需在服务端配置为auth_sha1_v2_compatible），支持服务端自定义参数，最大客户端数量的10进制整数。

auth_sha1_v4（不建议）：对首个包进行SHA-1校验，发送随机客户端id(4byte)、连接id(4byte)、unix时间戳(4byte)，后续使用Adler-32校验，对包长度单独校验以抵抗抓包重放检测，长度混淆增大，UTC时间差不超过24小时。兼容原协议（需在服务端配置为auth_sha1_v4_compatible），支持服务端自定义参数，最大客户端数量的10进制整数。

auth_aes128_md5或auth_aes128_sha1（均推荐）：对首个包的认证部分使用Encrypt-then-MAC模式，抵御认证包的CCA攻击，防止各种探测和重防攻击，支持单端口多用户。服务器与客户端UTC时间差不超过24小时，针对UDP部分也有简单校验。此插件不能兼容原协议，支持服务端自定义参数，最大客户端数量的10进制整数。

auth_chain_a（强烈推荐）：对首个包的认证部分使用Encrypt-then-MAC模式，抵御认证包的CCA攻击，数据流自带RC4加密，支持单端口多用户，不同用户间的数据无法解密，每次加密密钥均不同。服务器与客户端UTC时间差不超过24小时，UDP部分也进行加密及长度混淆。建议将加密设置为none。此插件不能兼容原协议，支持服务端自定义参数，最大客户端数量的10进制整数，最小值可设置为1，实时响应客户端数量（至少需保持一个连接不断开）。

推荐使用auth_chain_a插件，其混淆能力和抗检测能力均较高，即使多人同时使用也难以被识别与封锁。同时，发布公开代理时，以上auth插件均可严格限制客户端数量（注意若使用auth_sha1_v4_compatible，则原协议下无此限制），auth_chain_a协议的限制最为精确。

混淆特性

说明：

• 20%/100%表示首包为20%，其余为100%速度（或带宽），其它的RTT大于0的混淆，前面的表示在性能上的表现。