动态端口下，用来建立连接的端口也会被封

[redstoneleo]

图中的这个端口使用时日一久就会被探测到进而屏蔽（和我以前猜测的差不多），所以是否可以考虑从动态端口范围内任意选一个用来建立连接的时候使用呢？

[mydogshitgold]

It is my understanding that you are using WebSocket for V2Ray transport. Are you also using TLS or plain TCP under WebSocket?

Have you considered other approaches such as masquerading V2Ray traffic as HTTPS traffic, hiding exit node behind relay nodes (such as CDN), or implementing V2Ray compatible protocols at the edge?

[mydogshitgold]

Also, if V2Ray fails to penetrate the firewall more exotic measures such as DNS tunneling or ICMP tunneling may work as a backup.

[redstoneleo]

Thanks for your reply!

It is my understanding that you are using WebSocket for V2Ray transport. Are you also using TLS or plain TCP under WebSocket?

It seemed I used plain TCP under WebSocket in the past, so using TLS will help ? My confirmation is as follows：

Have you considered other approaches such as masquerading V2Ray traffic as HTTPS traffic, hiding exit node behind relay nodes (such as CDN), or implementing V2Ray compatible protocols at the edge?

Using CDN will decrease the network speed, so I usually don't adopt this way. As for implementing V2Ray compatible protocols at the edge, it is currently out of my competence, I am not familiar with the Go programming language .

Also, if V2Ray fails to penetrate the firewall more exotic measures such as DNS tunneling or ICMP tunneling may work as a backup.

It seems the learning curve is high, so currently I just use the CDN approach as the fallback.

Overall , I think the dynamic port mechanism of v2ray is wonderful except the port used to establish the connection is fixed all the time, which I think is the downside.

[redstoneleo]

BTW, it seems TLS under WebSocket dynamic port mechanism is not available or provided by the one-key script I used

[mydogshitgold]

If you want to disguise V2Ray traffic as HTTPS traffic, it is best to avoid the dynamic port and use standard ports. It's very sinister to serve normal HTTPS on random ports.

If you want to use a CDN to relay V2Ray traffic, well known ports such as :443 or :8443 must be used.

With WebSocket over TLS, you can use uTLS or browser forwading to better hide your TLS client fingerprints.

If you want a robust proxy that is hardened against blocking, you need to have a deep understanding of the network stack, V2Ray, and write your own configuration instead of using preconfigured scripts, which are convenient but inflexible.

[mydogshitgold]

You can also put V2Ray servers behind popular web servers like NGINX, haporxy, Caddy, etc. to conceal TLS server fingerprints and serve a real website as a camouflage to counter active probing. CDN can also do this with edges.

[mydogshitgold]

It seems the learning curve is high, so currently I just use the CDN approach as the fallback.

That's why they might work in a hostile environment: fewer people use them because they're "hard"; firewalls rarely block them because they're exotic and perhaps harder to counter.

[redstoneleo]

Thanks for the great tips. Formerly , I used another one-key script and tried various combination of the protocols with 443 and 8443 ports, each of my configuration also put XRay servers behind NGINX, the uTLS option was also turned on, and also served a real website as a camouflage, but the ports was still blocked a few days later after setup, then I realized the dynamic port mechanism of v2ray and then adopted the approach, but it turned to be that the mechanism is also vulnerable to port blocking as stated above. I'll try your advice later if I am blocked again. Thanks buddy !

[sndnnlfhvk]

我恰恰相反，去年10月开始大规模封锁TLS的时候，我用了多年的基于TLS服务器被封(只封端口不封IP)。后来到处问身边的朋友，看看什么样的协议相当安全点，得出来的结论就是TCP动态端口裸奔存活时间最久。我现在就是用动态端口，不套TLS。 个人分析是因为不停的换端口，这样单个端口的流量不会很大。而以前我用TLS一般是被封端口，流量大的时候容易封。

[redstoneleo]

不停的换端口

我没有“不停的换端口”，也是用了好几个星期后被封用来建立连接的端口的

[1265578519]

本来还想说试试自动 换端口的，，，搜了一下发现别人已经试过了，都是秒封 不知道纯tcp流量会怎么样，不进行ws伪装域名之类，会不会好一点 但是v2的纯tcp流量抓包发现首个数据包有个固定的特征码用于验证，有个固定的头部，目前已知的是SS AEAD不受任何影响

[mydogshitgold]

IMO, using a dynamic port or cleartext traffic may not be a good solution for evading blocking. It would be easier for an adversary to detect the existence of V2Ray and block the living daylights out of your server. V2Ray's TLS transport may be flawed, but at least it provides a layer of plausible deniability.

Also, some of the blocking is implemented as TCP reset attacks. Using a UDP-based transport (mKCP, QUIC) might get around this.

Anyway, that's just me speculating.

[nursery01]

Also, some of the blocking is implemented as TCP reset attacks. Using a UDP-based transport (mKCP, QUIC) might get around this.

yes, udp very good!!!

[nursery01]

如果埠被封了的話，請不要再嘗試更換埠，因爲這樣有可能會導致ip被封鎖 如果ip被封鎖，那麽ssh將是不可用的

[sndnnlfhvk]

本来还想说试试自动 换端口的，，，搜了一下发现别人已经试过了，都是秒封 不知道纯tcp流量会怎么样，不进行ws伪装域名之类，会不会好一点 但是v2的纯tcp流量抓包发现首个数据包有个固定的特征码用于验证，有个固定的头部，目前已知的是SS AEAD不受任何影响

我用的就是TCP动态端口，没问题。你问的不知道纯TCP流量会怎样，我这种方式本身就是VEMSS 纯TCP流量不停换端口，目前还行。

楼上说的”如果埠被封了的話，請不要再嘗試更換埠，因爲這樣有可能會導致ip被封鎖 如果ip被封鎖，那麽ssh將是不可用的“ 本身没错，但是动态端口是很短时间就换端口，在端口被封之前已经换了。所以就没这个问题。

[nursery01]

楼上说的”如果埠被封了的話，請不要再嘗試更換埠，因爲這樣有可能會導致ip被封鎖 如果ip被封鎖，那麽ssh將是不可用的“ 本身没错，但是动态端口是很短时间就换端口，在端口被封之前已经换了。所以就没这个问题。

什麽還有這種操作。。。 但是如果未來機制升級，檢測多個埠被封了，直接就封ip不是更省事，因爲主要的商業業務是不會頻繁換埠，誤殺也不會有太大損失

[1265578519]

我用的就是TCP动态端口，没问题。你问的不知道纯TCP流量会怎样，我这种方式本身就是VEMSS 纯TCP流量不停换端口，目前还行。

很遗憾，这几天测试下来，纯tcp也会被封，而且是和tls一样精准封ip

[redstoneleo]

我目前用http的动态端口，还正常

[Bigbox02]

动态口浏览普通网页，不去跑油管啊大流量或访问敏感类域名没啥问题，我就是年初ws+tls被封443端口，改用ws动态沿用至今

[mbicc]

什么时候可以更新把监听端口改成一段端口,大家看服务器性能设置监听范围,其实目前很多就是监听端口被封了,传输再动态也没有用了. 目前用KCPTUN更新了端口段,监听1000个端口完全不怕封了

[redstoneleo]

@mbicc 怎么用上你都说的KCPTUN？有没有简单方法如一键脚本之类的？

[Bigbox02]

之前被封的443，这几天看了下居然解封了，不知道是不是大范围动作还是个例，期间一直挂着动态端口在跑的

[fishblueone]

大概猜测 只要公开可以请求的HTTP/HTTPS数据，只要在这个返回数据上验证是否还有另一层加密数据，就能判断是否为可疑加密，然后打上标签观察该服务器的反向连接数据（ISP端）如果经常有单一IP长时间加密获取第二层或者以上的加密数据，就能判断为魔法

[github-actions[bot]]

This issue is stale because it has been open 120 days with no activity. Remove stale label or comment or this will be closed in 5 days