一、通过请求IP设定口IP

首先我们看下SSS数据包的走向：

A: 用户发出加密请求到SSS服务器

B: SSS服务器解密请求后转发到目标服务器

C: 目标服务器回应SSS服务器

D: SSS服务器加密回应返回给用户然后解密后使用

其中步骤B是影响出口IP的关键步骤，需要制定iptables规则修改源ip

理论上做SNAT处理即可，但SSS转发用户请求时端口由系统随机分配，目标服务器、端口不可预测。

简单说，从SSS出去的数据包，已经不是用户发出的那个包了，在sourcePort、destIP、destPort都不可控的情况下去修改sourceIP

结论：不可行

二、iptables Owner Match 方案

SSS作者clowwindy在#131给了参考方案：https://github.com/shadowsocks/shadowsocks/issues/131

通过iptables的Owner match来实现，前提是用不同的用户启动多个不同的SSS实例

Owner match支持–uid-owner、–pid-owner、–sid-owner、–cmd-owner匹配

很可惜我的vps上不支持–pid-owner，需要编译内核，遂放弃，决定采用 –uid-owner模式

思路是建几个用户分别启动SSS实例，并使用不同的端口(如1081、1082、1083)，再做简单的端口重定向

第一步、建立用户

第二步、多SSS实例配置
分别给实例指定不同的配置文件config1081.json、config1082.json、config1083.json，启动脚本如下

到此，多出口IP已经完成，SSS服务器上现有3个出口IP和N个不同的SSS组合，比如：
192.168.0.1:1081、192.168.0.2:1082、192.168.0.3:1083、192.168.0.1:1082、192.168.0.1:1083等等
作为轻微强迫症患者，实在受不了，想简化一下，只留一个1081对外开放:
192.168.0.1:1081(出口192.168.0.1)、192.168.0.2:1081(出口192.168.0.2)、192.168.0.3:1081(出口192.168.0.3)

第四步、简化
思路：禁止1082、1083的对外开放，并做个转发，192.168.0.2:1081 转发到 192.168.0.2:1082， 192.168.0.3:1081 转发到 192.168.0.3:1083