网站共用端口Shadowsocks-obfs的安装更新Nginx>Obfs方法

使用更先进的浏览器访问效果更佳。

网站共用端口Shadowsocks-obfs的安装更新Nginx>Obfs方法

shuanglengyunji

tofuliang 你可以看一下websocket的相关知识。

no-Dark

有一些想法，特意挖个坟。
前段时间陆续被墙两个服务器的 IP，分别用的是 SSR 与 Ss ，配置为一键脚本默认参数。无奈寻找出路，看到集合体的 Project V 很是激动，对着官方、白话文档研究了几天，最后参考了一篇 Steemit［1］的文章，配置了声称可以由网站转发流量、隐蔽性极佳的 WebSocket + TLS + Nginx，目前已经使用快两个月了，简单说一下感受。由于不是专业人士，只能说下主观感受。
前些天的两慧，不知道你们的服务器 IP 有没有被墙，我和小圈子用的两个 Project V 是一点干扰都没有受到。值得一提的是，用的还都是热门商家的服务器，就是 2.82 换 IP 的那家…
但我并不是来吹 V2 的，如果说既隐蔽又抗干扰的 V2 可以达到 100% 的 Online，但是在这 100% 的 Online 中，体验却只能说尚好。我之所以没有提交到 GitHub 上，是因为我也不知道是不是我本身的问题，应该如何描述这些问题。
主要表现在“断流”（？），客户端 v2rayNG 在 Android 常驻后，偶尔会收不到消息、没有网络。我不知道是其 Android 客户端不成熟，还是用 v2rayNG 而没有用 Actinium 的原因，又或是小米被提到过的断流现象、又可能是白名单不完善，总之与我印象中曾经的 Shadowsocks 系产品没办法比。
我其实不是来黑 V2 的，Project V 的速度很是恐怖，在安装 TCP-BBR 后，100兆的带宽访问 YouTute，可以稳定并峰值达到 102Mbps，不是亲身体验还不敢说。而且我 Windows 时间也不少，在 Windows 上却没发现有难耐的地方。所以我有些怀疑是我或者 Android 这些软体的问题，但我不知道如何解决，不过这些不好的体验确实难让我完全认为 V2 强于 Ss 系。
我认为 Ss 好于 V2 的方面是传输协议 Shadowsocks 更加成熟；但 V2 作者 Victoria Raymond 在 Telegram 称 VMess 特征更加弱，
观念为“最好使用小众代理软件”的逗比根据地博主，文章涉及各类科学上网干货，包括 Brook、goflyway、Lightsocks，唯独没有提及 V2，我认为有他的道理（虽然只字未提有些反常，并且几乎没有原版 Shadowsocks 的内容）
相比其他，Android 的 Shadowsocks 客户端更好看…
其实说了这么多，我也是想配置原版 Shadowsocks，即便是作为备用也好。但是有很多感觉奇怪的地方，比如：都说在曾经，有混淆的 SSR 更好，直到 Ss 也推出了 obfs，重安全的 Ss 才与重混淆的 Ss “打成平手”，但为什么感觉 Ss 没有将 obfs 放在应有的位置呢？Win 与 And 都需要额外 obfs 才可以使用它，而且网上关于 obfs 的笔墨又很少，感觉像是小众配置，参照 V2 的配置思路，我试着搜索 Nginx 转发 Ss 流量，找到这里。而且我找到了一篇关于 Ss、前前后后最详细的说明［2］，感觉 obfs 也被他使用了啊。但是网上关于 obfs 的文章少到反常，很不解。而如果不使用 obfs，就是常规配置，这种配置我曾使用、被墙过，不愿再次使用了，包括使用混淆的 SSR 也被墙过。
说了这么多，我其实就像问：Shadowsocks 系代理，应该如何配置，才可以将隐蔽性达到最高？不怕麻烦！
［1］https://steemit.com/v2ray/@laosan/v2ray-websocket-ws-tls-nginx-bbr-cdn-wordpress
［2］https://web.archive.org/web/20171012042606/https://sspai.com/post/39828

LetITFly

no-Dark SSR 的 TLS 混淆并不完美，换用 http-simple 走 80 端口可能会稳一些。SSR 也支持和网站在一起伪装，可以看看 breakwa11 的 blogger。Android 端 v2ray 有这样的问题的话，那么我暂时先用 SSR 好了。

新原版 SS 似乎刻意拆分这些功能，不知道为什么。逗比根据地不再推荐原版 SS 可能就是因为如今的它过于繁琐而也没有特别出彩的地方。

no-Dark

断流还有一种可能，就是开启了 Mux。
作者称 VMess 的特征是最弱的，我看反了…
https://t.me/v2msg/58

KazamaSion

no-Dark In DawnDIY's deleted tweet, he indicated that there're some unreasonable designs in v2ray-core at that time.
I know this tweet because this is the tweet he replied to me to tell me my criticizing is not fair to him about the broken traffic and my irresponsible surmise. I apologized to him at that time.

N.B. This issue may be improved today.

no-Dark

作为小白，我更偏向于用成熟、人多的项目…毕竟遇到问题可以更容易问出答案。这也是我没有用小众代理的原因。
关于 V2，我查看了下 Play 商店对 Actinium 与 v2rayNG 的评论，有不少提到断流现象，作者也有“服务端版本要高于客户端”的言论，这是我没有注意的，还有关于小米曾有过的断流现象。还不确定到底是哪个环节出现的问题…建议还是实际体验下，毕竟 V2 速度、稳定方面没得挑。
还有人评论提到白名单，如果没记错，破娃主导过这个项目，其实我比较看重这个，我希望国内等一众网站就直连，不走代理，虽然 V2 也有将 .cn 与 IP 为大陆的网站直连，但感觉还是没有 Ss 系成熟，所以我想移动设备用 Ss。
真是矛盾啊…（在我看来）历时久的项目成熟，历时短的项目干扰少。看来想“兼得”得搭配使用呢～
其实我不想用 SSR 是基于这层原因，不知道道理对不对：SSR 已经不再维护了，面对学习愈加强大的墙，也许会撑不了多久…
SSRR 的言论太少，也许还没有得到主流认可。
逗比如果不写 Ss 可以理解为他认为 SSR 比 Ss 好，两者写一个就行，那对 V2 只字不提就很奇怪了耶即便认为不好，也得说明下吧…
没办法借鉴逗比大佬的思路，还有另一位在少数派撰稿的大佬（原文被删，不过作者本人也在 Medium 备份过，［1］），浏览完他的文章，我认为不论是服务器的选择，还是对于优化的罗列，我认为他肯定对代理很有研究，他在文字也提到了 SSR 与 V2：
————————————
· Shadowsocks-libev 率先支持 AEAD 加密，并向 ShadowsocksR 学习引进了 Obfs (Simple-Obfs，但与前者原理有所不同)，且提供稳定的周期性更新；关于未来，ShadowsocksR 更倾向于 none 加密策略，而 Shadowsocks-libev 则倾向于传统的加密策略，两者有不同的侧重点 (ShadowsocksR 更侧重消除特征以避免被检测识别，而 Shadowsocks-libev 则追求更高的安全性)，综合起来并无优劣之分
‎ · 比 V2Ray 这种科学上网的集合体，Shadowsocks 在服务端更加轻量，单一协议完善程度更高
————————————
‎所以既然他对代理都如此了解，最后却选择了 Ss，肯定有他的道理。我虽然不知道为什么…只能照搬他的思路：也考虑 Ss 而不是 SSR 了。
最后，至于为什么将 obfs 推广，反而遮掩很深，我试着理解为……大家心照不宣…？
［1］https://web.archive.org/web/20171012042606/https://sspai.com/post/39828

no-Dark

逗比原话：
SS-libev版的话，主要是现在也是被针对的厉害，墙的也不少，所以我也没有写他的想法了。。
至于 V2ray 相对比较复杂，考虑到我网站大都是小白新手，想要让他们完全理解V2ray，我怕是语文还不行。。。
而因为模块化太灵活，也导致一键脚本不好写呀，目前一键脚本实现方法也就是预设一堆模板。。。
对于 V2ray 我是无从下手，不知道该怎么搞才好

wclmgcd

80端口成功,但改用443端口不成功(已经配置证书,网站可以访问但ss不行,用命令查看是已启动的),

soundghost

感谢楼上各位的讨论与分享，我照着教程把我的nginx配置改了，已经成功实现了伪装。
简单介绍一下我的想法，在vps上只对外开放80、443两个端口，除了提供http服务外，ss-libev隐藏于80端口后，v2ray隐藏于443端口后，设置好证书后，我的nginx增加了下面两处代码：
80：

 location = /{
			proxy_redirect off;
			proxy_http_version 1.1;
			proxy_set_header Upgrade $http_upgrade;
			proxy_set_header Connection "upgrade";
			if ($http_upgrade = "websocket") {
				proxy_pass http://127.0.0.1:12345;
            }
        }

443：

 location = /{
			proxy_redirect off;
			proxy_http_version 1.1;
			proxy_set_header Upgrade $http_upgrade;
			proxy_set_header Connection "upgrade";
			if ($http_upgrade = "websocket") {
				proxy_pass http://127.0.0.1:54321;
			}
        }

在ios端连接80的ss-libev或者链接443的v2ray都成功。
然后我想配置浏览器访问80端口的时候强制跳转到443，在80端口的代码下增加了一句：
rewrite ^(.*)$ https://$host$1 permanent;
就出问题了，具体故障为：
之前正常走80端口的ss-libev失效，但走443端口的v2ray不受影响。
我明白应该是这句跳转代码把ss的流量引向了v2ray导致的，但却不知道如何纠正。
我希望达到的目的：
1.浏览器用http访问的时候强制走https
2.ss-libev走80
3.v2ray走443
以上三点互不影响。

谢谢，请不吝赐教

KazamaSion

Here is the example that points out the configure which can make you use port 443 with ss-libev(with obfs-tls) and regular website at the same time compatibly:

P.S. For there's no time for me, I could only paste the key part here.

Configure arguments: --with-stream=dynamic --with-stream_ssl_module --with-stream_ssl_preread_module

Nginx.conf

load_module "modules/ngx_stream_module.so";

http {
    server {
        server_name  regular-website.tld;
        listen       127.0.0.1:1244 ssl http2;

        location / {
        }
    }
}

stream {
    map $ssl_preread_server_name $backend {
        obfs-domain.tld shadowsocks-obfs-tls;
        default nginx;
    }
    
    upstream shadowsocks-obfs-tls {
        server 127.0.0.1:4741;
    }
    
    upstream nginx {
        server 127.0.0.1:1244;
    }

    server {
        listen      443;
        proxy_pass  $backend;
        ssl_preread on;
    }
}

Trumeet

用 Docker 部署大法好啊（（（

HybridLifetime

Trumeet 你这让LXC/OpenVZ和小内存VPS很难受。

欧哈哈哈

挖一下坟，不知道有没有人解答我的问题，我在nginx添加
location / {
proxy_redirect off;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
if ($http_upgrade = "websocket") {
proxy_pass http://127.0.0.1:2052;
}
}
ss-libev+obfs用2052，网页用2086端口，然后套cf，网页能访问，但是安卓填域名和2086端口无法连接ss；安卓客户端直接填真实ip和2052端口能连接

欧哈哈哈

欧哈哈哈
2020/02/16 10:23:32 [error] 1131#0: *1139 upstream prematurely closed connection while reading response header from upstream, client: 171.8.133.132, server: 我的域名, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:2052/", host: "我的域名:2086"

« 上一页