trojan 使用 443 端口被封了 #597

doghappy · 2021-06-29T10:01:48Z

我使用 nginx 443 转发到 trojan，实现共用 443 端口，它一直工作得很好。但是在 2021/6/28 下午，443 端口被封了。有其他网友遇到这种现象吗？

doghappy · 2021-06-29T10:10:37Z

伪装的网站是 Welcome to CentOS 的默认网页，是否与这个有关系？

dotAge · 2021-06-29T12:43:14Z

我现在一直报dial tcp4 .... i/o timeout

dotAge · 2021-06-29T12:53:24Z

确认80端口可连接，但443则连接失败，手机数据信号及多个宽带网络都不行了。
Trojan服务器端换443以外的端口可行吗？

doghappy · 2021-06-29T13:13:13Z

我跟你的提示一样，最终确定是端口被封了。更换端口可以继续使用服务，但有网友反馈说，如果更换端口再次被识别，可能会封锁 ip，请慎重。

如果只有一台 vps，尝试更换协议和端口。

我是中午看了一会油管后被封的。

wongsyrone · 2021-06-29T14:24:55Z

我现在一直报dial tcp4 .... i/o timeout

你这个也不是trojan-gfw的输出啊

doghappy · 2021-06-29T14:26:52Z

trojan服务端正常，这个是v2rayN客户端的输出。

dotAge · 2021-06-29T17:04:31Z

我现在一直报dial tcp4 .... i/o timeout

你这个也不是trojan-gfw的输出啊

我这个是clash for android的日志

dotAge · 2021-06-29T17:11:44Z

我跟你的提示一样，最终确定是端口被封了。更换端口可以继续使用服务，但有网友反馈说，如果更换端口再次被识别，可能会封锁 ip，请慎重。

如果只有一台 vps，尝试更换协议和端口。

我是中午看了一会油管后被封的。

如何更换服务器端口？

xiaobovlog · 2021-06-29T19:20:12Z

So do I, 6/28/2021

wongsyrone · 2021-06-29T21:45:49Z

共用 443 端口

其他共用的都有什么服务，伪装站怎么搭建的

BaiqingL · 2021-06-29T22:12:24Z

换个端口搭建服务，我之前也有遇到这个问题。

kgiflwl · 2021-06-29T23:34:14Z

2021/6/29中午开始不能访问，ping.pe正常，port.ping.pe发现443端口被封，80端口到目前2021/6/30，trojan仍然可以接到http请求。伪装网站是每月定期从某hub.io搬运，时常有随机更新。

可能是某种行为pattern被标记了。

wongsyrone · 2021-06-29T23:37:36Z

搭建是否使用一键脚本，如果使用给出链接地址

kgiflwl · 2021-06-29T23:42:49Z

搭建是否使用一键脚本，如果使用给出链接地址

从头搭建的，根据https://trojan-gfw.github.io/trojan
已正常使用一年有余，每次有新release都会更新，用的客户端：自己在openwrt编的、shadowrocket、igniter

wongsyrone · 2021-06-29T23:44:44Z

伪装站的nginx配置和伪装站源码

kgiflwl · 2021-06-29T23:50:47Z

伪装站的nginx配置和伪装站源码

伪站源mlcommons.org，nginx是原始debian 10 deb包默认配置未修改（稍后附上），只用80，用trojan伪装nginx 443。cert是letsencrypt对应debian+nginx，每90天更新

kgiflwl · 2021-06-30T00:03:04Z

nginx是原始debian 10 deb包默认配置未修改（稍后附上）

nginx.zip

kgiflwl · 2021-06-30T00:13:08Z

trojan log，能看到从80进去的请求被识别，trojan转给nginx。443发过去的已经收不到了。除了443，其它维护端口都是通的。

wongsyrone · 2021-06-30T00:24:56Z

目前上面几位看不出问题，贴一下目前暂时没有被封锁的流程：

nginx server_tokens off
nginx 监听0.0.0.0:80 并仅负责301到443， nginx监听127.0.0.1:80 托管伪装站
trojan监听0.0.0.0:443，负责接入所有外部443请求

kgiflwl · 2021-06-30T00:27:16Z

nginx server_tokens off

这个我没设，可能的原因之一

xhrm · 2021-06-30T01:11:05Z

近期多个服务器443被封，其他端口正常，从海外访问正常，国内GG

kgiflwl · 2021-06-30T03:34:09Z

我们应该尽可能的列举使用习惯、流量习惯、客户端习惯这些，看看pattern标记的漏洞在哪里。trojan protocol本身已经论证过不少回了，能被标记的概率比较小。

BaiqingL · 2021-06-30T03:47:17Z

nginx server_tokens off

这个我没设，可能的原因之一

这个只是表明不会反馈nginx版本，是个常见的安全措施，不至于成为原因之一。

strongbugman · 2021-06-30T06:57:12Z

我这的伪装站挂了，不知道是不是这个原因

xiaobovlog · 2021-06-30T07:13:36Z

有可能是伪装站挂了的原因，我的也变成了nginx的默认页面了

keengrass · 2021-06-30T08:50:23Z

换个端口搭建服务，我之前也有遇到这个问题。

换个端口搭建会不会容易直接封IP了？（裸奔）

ghost · 2021-06-30T09:30:32Z

我两个节点作为备份，所以我的ssh流量我也走trojan，这样可以突破公网对ssh的限制。以前都一直好好的，这几天不行了。我节点可以上github.com和google.com，但是ssh连不上。我不知道是否ssh over tls被GFW识别了？

这两天两个节点也挂了一个，换了IP只管了几个小时。还好还有一个可以用的。

是无差别封锁还是trojan不再坚挺了呢，我的节点应该2年多了，一直挺稳定的，以前关键时期都没出过问题，这次挂了。

earth-5G · 2021-06-30T09:59:22Z

我两个节点作为备份，所以我的ssh流量我也走trojan，这样可以突破公网对ssh的限制。以前都一直好好的，这几天不行了。我节点可以上github.com和google.com，但是ssh连不上。我不知道是否ssh over tls被GFW识别了？

这两天两个节点也挂了一个，换了IP只管了几个小时。还好还有一个可以用的。

是无差别封锁还是trojan不再坚挺了呢，我的节点应该2年多了，一直挺稳定的，以前关键时期都没出过问题，这次挂了。

无差别i封锁之前64就大面积封杀了一次，现在我i在这里还一切安好！

sheiy · 2021-07-11T06:04:45Z

已恢复。。。

ningfeiyu · 2022-02-02T04:34:17Z

之前好像也是这么回事，法定节假日就会这样几天。。。。真是有病。

doghappy · 2022-02-02T04:39:38Z

443 这两天再次被封，是直接封锁高危ip段吗？

ningfeiyu · 2022-02-02T04:59:34Z

我感觉就是敏感节日就会这样。。。 HeroWong ***@***.***> 于2022年2月2日周三 12:39写道：

…

443 这两天再次被封，是直接封锁高危ip段吗？ — Reply to this email directly, view it on GitHub <#597 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANHMWJUGWIY6X45BJ6SMVTUZCYRLANCNFSM47PYHMRQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

free-znet · 2022-02-11T10:57:11Z

我也被封了，443端口，不过我没使用后过了几天又好了，要是能支持 cdn 就好了。。

ningfeiyu · 2022-02-18T07:53:31Z

过年期间封了半个月443端口，今天试一下又好了。中间还重新安装了一遍不知道咋回事。。。 trojan ***@***.***> 于2022年2月11日周五 18:57写道：

…

我也被封了，443端口，不过我没使用后过了几天又好了，要是能支持 cdn 就好了。。 — Reply to this email directly, view it on GitHub <#597 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANHMWO2BRSFMCZRGVTAAFLU2TTRHANCNFSM47PYHMRQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

chenmin1992 · 2022-03-03T02:57:02Z

我也被封了，443端口，伪装站是一个 html 模板，封之前使用腾讯云的轻量服务器通过 iptables 转发流量来着，从 2022/02/25 到 2022/03/02 期间封禁，3号早上通过 https://port.ping.pe/ 测试端口已经解封，服务可以正常使用。
麻烦官方作者查看一下是不是被识别了流量，还是其他特征识别的。

keengrass · 2022-03-03T03:11:37Z

和流量大小有关系。BAN了解了，解了又被ban，换端口也是一样，最近一直在反复。感觉这个脚本已经不能再用了。

ningfeiyu · 2022-03-04T02:10:08Z

你是一直看YouTube吗？我改了一次端口后现在就没ban了。我之前就是会看youtube直播，视频。说说你们被ban之前的操作看。 keengrass ***@***.***> 于2022年3月3日周四 11:11写道：

…

和流量大小有关系。BAN了解了，解了又被ban，换端口也是一样，最近一直在反复。感觉这个脚本已经不能再用了。 — Reply to this email directly, view it on GitHub <#597 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANHMWOLUEV6UDVI7XDUFU3U6AUXHANCNFSM47PYHMRQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

lalinking · 2022-04-01T03:37:57Z

被封来报道。
同样是443阵亡，80仍然正常。
我是俄罗斯的vps。

eelzs · 2022-04-03T07:40:48Z

我是2月开始出现被封，更换ip后，大约2周会再次封，平常不看视频，只搜索资料时用用。

Mao-jiawei · 2022-04-03T07:48:45Z

我是2月开始出现被封，更换ip后，大约2周会再次封，平常不看视频，只搜索资料时用用。

我有个方案写个crontab任务每2小时stop一次trojan 当要用的时候登录服务器手动起服务

billowing · 2022-04-07T03:37:29Z

我今天也被封了，今年被封了很多次了，腾讯云的轻量服务器，好像也是昨天看了油管，今天就挂了.......

imxyd-com · 2022-04-13T05:55:38Z

是的，我最近被封了很多端口，而最近和之前最大的变化是我和朋友都在居家看netflix。所以我也认为是持续大流量造成的“宁可杀错不可放过”。

…

------------------ 原始邮件 ------------------ 发件人: ***@***.***>; 发送时间: 2022年4月13日(星期三) 中午1:51 收件人: ***@***.***>; 抄送: ***@***.***>; ***@***.***>; 主题: Re: [trojan-gfw/trojan] trojan 使用 443 端口被封了 (#597) #可以发现，在被封的例子中基本都有个共同点：都是在流量大量交换后被封（如看youtube视频）。个人认为GFW目前由于trojan的特殊的一般性（使用最常见的https）无法辨认一个网站是否存在代理，因而对短时间内大流量交换的网站进行端口阻塞TCP封锁(阻断)。解决端口阻塞，若单纯地更换trojan端口，引用一段话回应：“GFW之所以单独封一个端口，可能原因就是吃不准到底是不是代理，如果你很快就换了端口继续做代理，那么GFW就认为很大概率是代理，于是就可以封禁了。”（此处的封禁包括但不限于：封ip，DNS劫持，TCP RST阻断）So，那么目前可靠的解决方法便是套CDN（比如cloudflare），当然这是trojan-go才可实现的；或者更换为 v2ray（或xray）+ws+tls（但个人测试trojan-go+CDN效果好于v2ray+ws+tls）。最后补充一点：建议伪装网站用动态的（比如cloudreve网盘？），这样才说得通大流量交换（感觉GFW是有人工审查网页的，不然你想想对着个静态网页撸出了几G流量，怎么能说得清）。以上个人拙见，包含自己的理解，可能有所偏差。参考： https://doubibackup.com/_2y705r7-2.html http://www.oneyearago.me/2019/06/14/learn_gwf/ — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

YongChingShieh · 2022-04-14T11:18:10Z

根据我的观察在ipv4的443端口会被封锁但ipv6不会理由如下
在2台oracle的vps上分别搭建了v2ray 和trojan 同时开启ipv4和ipv6
经过一段时间后搭建trojan的机器 ipv4 443端口被封锁而ipv6没有问题 v2ray的ipv4和ipv6都没有问题

imxyd-com · 2022-04-14T12:15:45Z

所以，v2ray是什么原因导致没有问题？从理论来说，trojan不会被成功探测。

…

------------------ 原始邮件 ------------------ 发件人: "YongChing ***@***.***>; 发送时间: 2022年4月14日(星期四) 晚上7:18 收件人: ***@***.***>; 抄送: ***@***.***>; ***@***.***>; 主题: Re: [trojan-gfw/trojan] trojan 使用 443 端口被封了 (#597) 根据我的观察在ipv4的443端口会被封锁但ipv6不会理由如下在2台oracle的vps上分别搭建了v2ray 和trojan 同时开启ipv4和ipv6 经过一段时间后搭建trojan的机器 ipv4 443端口被封锁而ipv6没有问题 v2ray的ipv4和ipv6都没有问题 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

YongChingShieh · 2022-04-15T10:14:58Z

个人推测是和运行机制有关系 v2ray是在网站后面运行而trojan是放在网站前面运行请参考下面的图示我在oracle上搭建也是和下面这个图一样

Mao-jiawei · 2022-04-15T14:23:35Z

个人推测是和运行机制有关系 v2ray是在网站后面运行而trojan是放在网站前面运行请参考下面的图示我在oracle上搭建也是和下面这个图一样

nginx还能代理v2ray？

YongChingShieh · 2022-04-16T06:40:27Z

请参考下面这个

v2ray服务端:

{
"inbounds": [{
"port": 8080,
"protocol": "vless",
"settings": {
"decryption": "none",
"clients": [{
"id": "",//uuid
"alterId": 64
}]
},
"streamSettings":{
"wsSettings":{
"path":"/proxy",
"headers":{}
},
"network":"ws",
"security": "none"
}
}
],
"outbounds": [{
"protocol": "freedom",
"settings": {}
}]
}

v2ray客户端

{
"log": {
"loglevel": "warning",
"access": "",
"error": ""
},
"inbounds": [
{
"port": 10083,
"listen": "127.0.0.1",
"protocol": "socks",
"sniffing": {
"enabled": true,
"destOverride": ["http", "tls"]
},
"settings": {
"auth": "noauth",
"udp": false
}
}
],
"outbounds": [
{
"protocol": "vless",
"settings": {
"vnext": [
{
"address": "域名或ip地址",
"port": 443,
"users": [
{
"encryption":"none",
"id": "",//服务端id
"alterId": 64
}
]
}
]
},
"streamSettings": {
"network": "ws",
"tlsSettings": {
"allowInsecure": true
},
"security": "tls",
"wsSettings": {
"path": "/proxy"
}
}
}
]
}

nginx:

server {
listen 80 default_server;
listen [::]:80 default_server;
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;

ssl_certificate /etc/letsencrypt/live/v.yching.gq/fullchain.pem;//证书路径
ssl_certificate_key /etc/letsencrypt/live/v.yching.gq/privkey.pem; //证书路径
ssl_session_timeout 1d;
ssl_session_cache shared:MozSSL:10m;
ssl_session_tickets off;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;

server_name _;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains;" always;
if ($scheme = http) {
return 301 https://$server_name$request_uri;
}
location /proxy {
if ($http_upgrade != "websocket") {
return 404;
}
proxy_redirect off;
proxy_pass http://127.0.0.1:8080;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
# Show real IP in v2ray access.log
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}

lalinking · 2022-04-18T02:39:52Z

我是2月开始出现被封，更换ip后，大约2周会再次封，平常不看视频，只搜索资料时用用。

我也是，不过我现在换成 nginx 走443，trojan 走80 （没换机器ip），一个月了暂时80没被封。

HappyLife-page · 2022-05-01T03:02:56Z

所以，v2ray是什么原因导致没有问题？从理论来说，trojan不会被成功探测。
…
------------------ 原始邮件 ------------------ 发件人: "YongChing @.>; 发送时间: 2022年4月14日(星期四) 晚上7:18 收件人: @.>; 抄送: @.>; @.>; 主题: Re: [trojan-gfw/trojan] trojan 使用 443 端口被封了 (#597) 根据我的观察在ipv4的443端口会被封锁但ipv6不会理由如下在2台oracle的vps上分别搭建了v2ray 和trojan 同时开启ipv4和ipv6 经过一段时间后搭建trojan的机器 ipv4 443端口被封锁而ipv6没有问题 v2ray的ipv4和ipv6都没有问题 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

v2ray: ws+tls+vless 两年多任何时候从未中断过，稳如泰山，无任何伪装站点和页面，默认nginx首页
trojan设计理念应该没问题，问题最大的地方在于，如果没有ws的path前置支持，任何伪装都没用。
这个逻辑是：v2ray的ws的path在被请求访问时默认是加密的，也即只有ws的支持才是最安全的伪装，任何人都获取不到你的真实访问url，这好比访问Java服务页面，浏览器地址栏是加密的一样，gfw不能因为这个地址是加密的就干扰你。
所以目前来看，最安全稳定的方案：ws是必不可少的（不使用ws而只靠伪装站，可能你的伪装站就是最大的特征）

HappyLife-page · 2022-05-01T03:07:00Z

所以，v2ray是什么原因导致没有问题？从理论来说，trojan不会被成功探测。
…
------------------ 原始邮件 ------------------ 发件人: "YongChing @.>; 发送时间: 2022年4月14日(星期四) 晚上7:18 收件人: _@**._>; 抄送: _@.>; @._>; 主题: Re: [trojan-gfw/trojan] trojan 使用 443 端口被封了 (#597) 根据我的观察在ipv4的443端口会被封锁但ipv6不会理由如下在2台oracle的vps上分别搭建了v2ray 和trojan 同时开启ipv4和ipv6 经过一段时间后搭建trojan的机器 ipv4 443端口被封锁而ipv6没有问题 v2ray的ipv4和ipv6都没有问题 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: _@_.*>

v2ray: ws+tls+vless 两年多任何时候从未中断过，稳如泰山，无任何伪装站点和页面，默认nginx首页 trojan设计理念应该没问题，问题最大的地方在于，如果没有ws的path前置支持，任何伪装都没用。这个逻辑是：v2ray的ws的path在被请求访问时默认是加密的，也即只有ws的支持才是最安全的伪装，任何人都获取不到你的真实访问url，这好比访问Java服务页面，浏览器地址栏是加密的一样，gfw不能因为这个地址是加密的就干扰你。所以目前来看，最安全稳定的方案：ws是必不可少的（不使用ws而只靠伪装站，可能你的伪装站就是最大的特征）

参考：https://www.happylife.page/107/2

sjush · 2022-12-08T02:37:06Z

我们应该尽可能的列举使用习惯、流量习惯、客户端习惯这些，看看pattern标记的漏洞在哪里。trojan protocol本身已经论证过不少回了，能被标记的概率比较小。

也许是youtube流量即使加密过也有宏观特征

toyo2333 · 2023-06-19T08:55:01Z

所以，v2ray是什么原因导致没有问题？从理论来说，trojan不会被成功探测。
…
------------------ 原始邮件 ------------------ 发件人: "YongChing @.>; 发送时间: 2022年4月14日(星期四) 晚上7:18 收件人: _@**._>; 抄送: _@.>; @._>; 主题: Re: [trojan-gfw/trojan] trojan 使用 443 端口被封了 (#597) 根据我的观察在ipv4的443端口会被封锁但ipv6不会理由如下在2台oracle的vps上分别搭建了v2ray 和trojan 同时开启ipv4和ipv6 经过一段时间后搭建trojan的机器 ipv4 443端口被封锁而ipv6没有问题 v2ray的ipv4和ipv6都没有问题 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: _@_.*>

v2ray: ws+tls+vless 两年多任何时候从未中断过，稳如泰山，无任何伪装站点和页面，默认nginx首页 trojan设计理念应该没问题，问题最大的地方在于，如果没有ws的path前置支持，任何伪装都没用。这个逻辑是：v2ray的ws的path在被请求访问时默认是加密的，也即只有ws的支持才是最安全的伪装，任何人都获取不到你的真实访问url，这好比访问Java服务页面，浏览器地址栏是加密的一样，gfw不能因为这个地址是加密的就干扰你。所以目前来看，最安全稳定的方案：ws是必不可少的（不使用ws而只靠伪装站，可能你的伪装站就是最大的特征）

用的vless+ws+TLS+Nginx，其他的方案和你的基本一样。Nginx在前面通过tls访问，vless内容通过路径转发给xray。

不同的是，我在nginx做了个转发。就是直接访问域名的话，跳到别的站的页面比如bing.com，或者某个网盘的域名，或者下载站的域名

   location / {
          proxy_pass https://bing.com; #伪装网址
          proxy_redirect off;
          proxy_ssl_server_name on;
          sub_filter_once off;
          sub_filter "bing.com" $server_name;
          proxy_set_header Host "bing.com";
          proxy_set_header Referer $http_referer;
          proxy_set_header X-Real-IP $remote_addr;
          proxy_set_header User-Agent $http_user_agent;
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
          proxy_set_header X-Forwarded-Proto https;
          proxy_set_header Accept-Encoding "";
          proxy_set_header Accept-Language "zh-CN";

用了半个月没任何问题，但是昨天晚上443被封了。这个会是因为设置那个伪装网址的做法不合适么？（相比你这种不设置任何伪装站点或者转发）

有什么改进建议呢？谢谢！

HappyLife-page · 2023-06-21T01:32:27Z

伪装不至于暴露
需要注意1,尽量使用ios系统
2,pc端尽量不要安装国产软件，如果可以应该使用mac系统

最近比较严，许多知名vps厂商都是重点关注对象，IP容易被特别关照，可以尝试小众地区

ArcCal · 2023-06-21T09:50:14Z

如果坚持要用trojan，客户端不要使用官方的，必封

birdeagles · 2023-07-06T09:29:18Z

所以，v2ray是什么原因导致没有问题？从理论来说，trojan不会被成功探测。
…
------------------ 原始邮件 ------------------ 发件人: "YongChing @.>; 发送时间: 2022年4月14日(星期四) 晚上7:18 收件人: _@**._>; 抄送: _@.>; @._>; 主题: Re: [trojan-gfw/trojan] trojan 使用 443 端口被封了 (#597) 根据我的观察在ipv4的443端口会被封锁但ipv6不会理由如下在2台oracle的vps上分别搭建了v2ray 和trojan 同时开启ipv4和ipv6 经过一段时间后搭建trojan的机器 ipv4 443端口被封锁而ipv6没有问题 v2ray的ipv4和ipv6都没有问题 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: _@_.*>

v2ray: ws+tls+vless 两年多任何时候从未中断过，稳如泰山，无任何伪装站点和页面，默认nginx首页 trojan设计理念应该没问题，问题最大的地方在于，如果没有ws的path前置支持，任何伪装都没用。这个逻辑是：v2ray的ws的path在被请求访问时默认是加密的，也即只有ws的支持才是最安全的伪装，任何人都获取不到你的真实访问url，这好比访问Java服务页面，浏览器地址栏是加密的一样，gfw不能因为这个地址是加密的就干扰你。所以目前来看，最安全稳定的方案：ws是必不可少的（不使用ws而只靠伪装站，可能你的伪装站就是最大的特征）

用的vless+ws+TLS+Nginx，其他的方案和你的基本一样。Nginx在前面通过tls访问，vless内容通过路径转发给xray。

不同的是，我在nginx做了个转发。就是直接访问域名的话，跳到别的站的页面比如bing.com，或者某个网盘的域名，或者下载站的域名
   location / {
          proxy_pass https://bing.com; #伪装网址
          proxy_redirect off;
          proxy_ssl_server_name on;
          sub_filter_once off;
          sub_filter "bing.com" $server_name;
          proxy_set_header Host "bing.com";
          proxy_set_header Referer $http_referer;
          proxy_set_header X-Real-IP $remote_addr;
          proxy_set_header User-Agent $http_user_agent;
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
          proxy_set_header X-Forwarded-Proto https;
          proxy_set_header Accept-Encoding "";
          proxy_set_header Accept-Language "zh-CN";
用了半个月没任何问题，但是昨天晚上443被封了。这个会是因为设置那个伪装网址的做法不合适么？（相比你这种不设置任何伪装站点或者转发）

有什么改进建议呢？谢谢！

我的和你的一樣，用nginx做僞裝，就是web+ws+tsl+v2ray，有一個vps剛建好就被封了，另一個用了兩天也挂了。我懷疑這種方式的某個特徵已經能被GFW探測出來，所以才被封的。如果不做改進繼續建站，結局也是一樣。可以試試把nginx的監聽端口換了，如果還是被封，十有八九就是被探測了，如果能繼續運行，那就是443被針對。
因爲本來這樣做法是把加密數據僞裝成HTTPS放在HTTPS這個森林裏，結果可能這棵樹長得太特別了，所以被發現

ArcCal · 2023-07-06T09:57:17Z

所以，v2ray是什么原因导致没有问题？从理论来说，trojan不会被成功探测。

谁说的trojan不会被成功探测?

birdeagles · 2023-07-06T15:14:09Z

所以，v2ray是什么原因导致没有问题？从理论来说，trojan不会被成功探测。

谁说的理论来说，trojan不会被成功探测

trojan已经可以被精准识别了，请参看下面的视频

https://www.youtube.com/watch?v=Z_URro3bZqM

doghappy added the bug label Jun 29, 2021

doghappy assigned GreaterFire Jun 29, 2021

qeatzy mentioned this issue Jun 25, 2022

[讨论]性能怎么样,功能方面和实现方面如何设计的。 enfein/mieru#8

Closed

trojan 使用 443 端口被封了 #597

trojan 使用 443 端口被封了 #597

Comments

doghappy commented Jun 29, 2021

doghappy commented Jun 29, 2021

dotAge commented Jun 29, 2021

dotAge commented Jun 29, 2021

doghappy commented Jun 29, 2021

wongsyrone commented Jun 29, 2021

doghappy commented Jun 29, 2021

dotAge commented Jun 29, 2021

dotAge commented Jun 29, 2021

xiaobovlog commented Jun 29, 2021

wongsyrone commented Jun 29, 2021

BaiqingL commented Jun 29, 2021

kgiflwl commented Jun 29, 2021

wongsyrone commented Jun 29, 2021

kgiflwl commented Jun 29, 2021 • edited Loading

wongsyrone commented Jun 29, 2021

kgiflwl commented Jun 29, 2021

kgiflwl commented Jun 30, 2021 • edited Loading

kgiflwl commented Jun 30, 2021

wongsyrone commented Jun 30, 2021

kgiflwl commented Jun 30, 2021

xhrm commented Jun 30, 2021

kgiflwl commented Jun 30, 2021

BaiqingL commented Jun 30, 2021

strongbugman commented Jun 30, 2021

xiaobovlog commented Jun 30, 2021

keengrass commented Jun 30, 2021

ghost commented Jun 30, 2021

earth-5G commented Jun 30, 2021

sheiy commented Jul 11, 2021

ningfeiyu commented Feb 2, 2022

doghappy commented Feb 2, 2022

ningfeiyu commented Feb 2, 2022 via email

free-znet commented Feb 11, 2022

ningfeiyu commented Feb 18, 2022 via email

chenmin1992 commented Mar 3, 2022

keengrass commented Mar 3, 2022

ningfeiyu commented Mar 4, 2022 via email

lalinking commented Apr 1, 2022

eelzs commented Apr 3, 2022

Mao-jiawei commented Apr 3, 2022

billowing commented Apr 7, 2022 • edited Loading

imxyd-com commented Apr 13, 2022 via email

YongChingShieh commented Apr 14, 2022

imxyd-com commented Apr 14, 2022 via email

YongChingShieh commented Apr 15, 2022

Mao-jiawei commented Apr 15, 2022

YongChingShieh commented Apr 16, 2022 • edited Loading

lalinking commented Apr 18, 2022

HappyLife-page commented May 1, 2022

HappyLife-page commented May 1, 2022

sjush commented Dec 8, 2022

toyo2333 commented Jun 19, 2023

HappyLife-page commented Jun 21, 2023

ArcCal commented Jun 21, 2023 • edited Loading

birdeagles commented Jul 6, 2023

ArcCal commented Jul 6, 2023 • edited Loading

birdeagles commented Jul 6, 2023

kgiflwl commented Jun 29, 2021 •

edited

Loading

kgiflwl commented Jun 30, 2021 •

edited

Loading

billowing commented Apr 7, 2022 •

edited

Loading

YongChingShieh commented Apr 16, 2022 •

edited

Loading

ArcCal commented Jun 21, 2023 •

edited

Loading

ArcCal commented Jul 6, 2023 •

edited

Loading