搭建基于nextjs的文档网站程序ixd

 首先fork此项目https://github.com/iambabyninja/xtls-docs ，我fork后，得到的项目地址是

 https://github.com/brightmann/ixd

 编辑https://github.com/brightmann/ixd/blob/main/package.json，把next的版本改为最新版16.3.5

 在这里https://github.com/brightmann/ixd/tree/main/content/docs ，新建源帖fh.mdx,内容为：

---
title: 战马
description: 这是一篇文章
---

此处写正文或html codes.

（详见 https://github.com/brightmann/ixd/blob/main/content/docs/fh.mdx?plain=1）

 然后，访问vercel.com/new ,导入项目 https://github.com/brightmann/ixd ，

 在Build Command栏填入npm run build
 在Install Command栏填入npm install --force

 点击底部的deploy按钮，等待部署完成。部署完成后，我得到网址:

 https://ixd-nine.vercel.app/docs

项目地址：

 https://github.com/iambabyninja/xtls-docs 

  https://github.com/brightmann/ixd

 演示网站地址： https://ixd-nine.vercel.app/docs 。在网站的左侧，可以看到同一天发表的帖子是按字母顺序，从上到下排列的：

 https://ixd-nine.vercel.app/docs/ce

 https://ixd-nine.vercel.app/docs/fh  （能显示视频）

 https://ixd-nine.vercel.app/docs/life-advice

 https://ixd-nine.vercel.app/docs/test

 

 

chromium浏览器伪造sni工具网页版

 SNI规则来源：

Cealing Host Up 2 Date 

自我介绍

Cealing Host 存储库: 用于管理最新的内置伪造规则

• 部分使用该规则的项目: Sheas Cealer, Sheas Cealer Droid

词汇解释

Sheas Cealer Dictionary or Cealer Dict

注意事项

1. 部分特殊网站的伪造请参考 特殊网站伪造教程
2. 本项目仅收录满足一定要求的网站，但受限于篇幅等，该要求无法在此处写出
3. 本项目仅供测试 Sheas Cealer 的 SNI 伪造效果，无意绕过任何国家审查设备的审查
4. 本项目非常欢迎大家贡献自己的伪造规则，欢迎提交 PR，Issue，也欢迎通过其他方式告诉我

文件地址

1. Cealing Host (内置规则): https://github.com/SpaceTimee/Cealing-Host/raw/main/Cealing-Host.json (镜像)
2. Cealing Host R (Rutube 视频资源规则): https://github.com/SpaceTimee/Cealing-Host/raw/main/Cealing-Host-R.json (镜像)

Cealing Host A 和 Cealing Host P 已弃用，不再维护

其他规则

c15412/Cealing-Host (部分规则添加多 ip 优选功能): https://github.com/c15412/Cealing-Host/blob/main/Cealing-Host.json

这些伪造规则由其他维护者维护，使用前请自行检查

格式文档

Cealing Host Documentation

from  https://github.com/SpaceTimee/Cealing-Host

----------------------------------------------------------------------

 Windows客户端：

 Sheas Cealer

自我介绍

Sheas Cealer: 一只基于 WPF(.Net8) 的桌面端 SNI 伪造工具

• 适用平台: Windows (Win10 之前的系统版本请使用 1.1.0) (其他平台请参考相关项目)

注意事项

1. 内置伪造规则在 Cealing Host 存储库 持续更新
2. Sheas Cealer 更新时不会覆盖已有的伪造规则，如需与上游同步，需点击更新上游规则按钮，或手动修改覆盖
3. 本项目及所有相关资源仅供抵御网络非法监听和开展网络安全研究使用，无意绕过任何国家审查设备的审查
4. 为避免不必要的麻烦，使用前请先阅读用户协议
5. Sheas Cealer 仍处于开发阶段，但每个正式版发布前会尽量确保其稳定可用

用户协议

1. 隐私政策
2. 使用协议

下载地址

1. Github: https://github.com/SpaceTimee/Sheas-Cealer/releases
2. 群文件 (参与内测): 参考联系方式

出于不可抗力因素，Sheas Cealer 暂时无法再提供蓝奏云下载地址，在此依旧感谢蓝奏云一直以来的免费分发服务

安装方式

1. Setup 安装器 (首选): 下载 Sheas Cealer Setup.exe 并运行 -> 按照提示设置即可安装
2. Zip 压缩包 (免安装): 下载 Sheas Cealer Zip.zip 并解压 -> 完成后即可直接使用

Scd 版本: Scd 版本内置 .Net 运行时，可在缺乏 .Net 运行时的环境下运行，但代价是更大的文件体积以及更差的跨平台能力，如果没有特殊原因，不建议使用 Scd 版本

食用文档

术语解释、软件食用、项目构建等文档请参考**Sheas Cealer Docs**

可在 Github Wiki 共同参与文档编写

项目原理

利用 Chromium 内核的启动参数特性伪造 SNI 拓展标记，详细原理可参考这篇文章

致谢名单

• kit: 为本项目提供全部的原理基础
• NiceBowl: 为本项目提供详细的原理说明

相关项目

1. Sheas Cealer Droid: Sheas Cealer 安卓端
2. Sheas Cealer Nix: Sheas Cealer 跨平台桌面端
3. Cealing Host: 最新的 Sheas Cealer 内置伪造规则
4. Sheas Dop: DNS 抗污染解析工具 (Sheas Cealer 全局净化子项目)
5. Sheas Nginx: Pixiv Nginx 启动器 (Sheas Cealer 全局伪造 × Pixiv Nginx 合作子项目)
6. Bot CealingCat: 提供 Sheas Cealer 相关服务的 Telegram Bot
7. Console HostChecker: Cealing Host 自动化检查脚本
8. Console HostGenerator: Cealing Host 自动化生成脚本

from  https://github.com/SpaceTimee/Sheas-Cealer

 

解决明文http泄露面板节点信息的问题，无需域名实现https加密

 

xray作者在官方tg频道发布了一个针对 X-UI 的安全建议，通过http访问面板进行配置的方式，会导致中间人gfw看到你的节点信息，简单理解就是你访问xui面板进行的所有操作都是明文的，gfw能看到你在xui上干了啥，搭建了什么节点，包括节点的密码和私钥这些都能看到，所以xray作者建议大家通过ssh加密隧道或者配置https访问，并表示这是一个很严重的安全风险。
当时大部分人都不以为意，认为gfw没那么闲，自己也没被gfw监控的价值。
首先肯定了作者提出的问题确实存在，其次解释了这样做的原因是因为教程面向的是零基础纯小白用户，操作步骤应尽量做到最简单，当然我也意识到了明文http的问题。
通过明文的http请求访问xui面板，但是传输的数据已经经过了节点的加密，gfw看不到内容，所以我也觉得这并不是什么大问题

接着这个问题就被搁置了，直到后来，有个Russia用户又把这个问题挖了出来，反映了各种web面板的默认配置会导致面板被别人扫描，并且扫描出来的大部分都还是使用http明文的方式访问面板，意识到问题比想象中更大之后，xray作者发布了一个pr，要求所有基于xray的web面板在公网上必须强制且只能通过加密通道访问，否则就从官方列表中移除推荐，
至此长达将近一个月的激烈讨论就此展开，具体讨论了啥大家就自己去看吧
简单总结就是反方表示没必要强制，只要提醒用户就好了，剩下的就让他自己选择，正方表示必须强制执行，如果提醒有用的话扫描结果就不会出现那么多http面板了。
最终结果是遵循了这个规定的web面板得以在xray官方推荐列表中保留，而没有遵循的面板则被移除了，其中就有我们熟悉的x-ui和3x-ui，之后3x-ui的作者发起了一个投票，最终有将近一半的希望保留http访问，可见分歧依旧很大，大家也可以在评论区留下你的看法

毕竟面板确实还是通过http的访问方式，如果你关闭了代理工具，或者在代理工具的分流规则是走直连的情况下访问面板，则还是存在安全问题，虽然我们无法保证绝对安全，但应该在力所能及的情况下保证相对安全，所以接下来就来演示一下怎么确保你的web面板不会使用明文http访问。

我就以原版xui面板为例，已经停更很久了不推荐使用，我这里只是为了演示，你用其他面板的话也是同样的配置方式，这些用到的信息我会放在视频下方的说明栏，使用这条指令在vps上安装xui面板，设置面板访问端口为20000，安装完成之后，按照以前的教程是直接在浏览器里通过http的方式访问面板，但现在不可以这么做，因为http是明文的，我们得通过加密的方式去访问他，如果你当前翻墙的节点是可信节点，那么你可以通过你的节点访问xui面板，但如果你现在没有节点，那就可以通过当前vps的ssh端口转发功能实现加密隧道访问xui面板，这里填入vps的用户名，这里填入vps的ip地址，这里填入ssh的端口，默认为22，这里填写vps上xui面板的端口，刚才我设置的是20000，按你的实际填写，这里随便填一个本机的空闲端口，建议设置一样的20000，复制指令，打开本机命令行，注意是在这台windows电脑上执行指令，输入密码进行连接，连上之后，就能通过本机的20000端口访问xui面板了，打开这条localhost连接，成功进入了xui面板，好像我们的请求没有经过互联网，但实际上是经过了ssh加密隧道转发数据，所以中间人无法看到你在xui上做了什么操作，当你退出vps之后，这条ssh隧道就断开了，也就无法访问了，如果你是通过密钥登陆，可以在后面加入-i 然后填入密钥的文件路径，另外如果你只想做端口转发，不想登陆shell，可以在后面加入-N，这样就不会进入vps的shell了，面板又能通过ssh隧道访问了，但是每次登陆都要创建ssh隧道，感觉很麻烦，另外在默认配置下面板依旧通过http的方式暴露在公网，所以我们应该为其配置tls证书，考虑到不是所有人都买了域名，这里教大家申请免费的ip证书，进入这个网址，点击右上角的获取免费证书，输入邮箱和密码进行注册，邮箱不需要验证可以随便写，建议填写自己的邮箱可以收到提醒，点击下一步，点击创建新证书，在这里输入你vps的ip地址，点击下一步，选择90天，一直点击下一步，此时会选中免费方案，点击下一步，接着按照步骤执行，下载这个文件，等会要用到，接着在vps上执行这条指令创建文件夹，复制这个文件名，将这里替换掉，接着将刚才第一步下载的文件内容复制，粘贴到这里，复制整条指令到vps上执行，最后执行这条指令创建一个临时的http服务器，注意80端口不要被其他应用占用了，点击下一步，最后点击验证域名，不出意外的话此时就会给你的ip颁发证书了，显示成功，点击下载证书，将证书解压到桌面，通过sftp工具将证书上传到vps，可以通过realpath指令查看证书所在的完整路径，同目录下的这个private.key就是私钥，接着重新运行ssh端口转发，通过加密隧道访问xui面板，来到面板设置，在这里填入证书和私钥的文件路径，最后保存并重启面板，接着网页弹出了安全警告，则表明证书生效了，现在我们应该使用证书对应的ip地址直接通过公网使用https的方式访问xui面板，可以看到是正规CA机构颁发的有效证书，现在我们就能且只能通过https的方式访问xui面板了
另外套了tls之后只能保证数据被加密了，并不能防止被扫描，我们还需要为其配置路径，现在的面板默认配置都会为其配置路径，如果你用的面板没有路径，可以在这里随便输入一串字符当作路径，注意先复制保存，接着保存并重启面板，此时页面会弹出404错误，我们需要将刚才的路径放在这个位置，重新访问就能成功进入xui面板了，有了https和路径的加持，就可以解决本次事件中讲到的安全问题了，有个小遗憾是ip证书90天到期之后要再操作一遍证书申请，并且一个账号只能创建3个证书，你可以花钱解决，也可以多注册几个号，反正又不用验证，毕竟ip证书都免费。

解决各种代理检测手段的方法，防止账号被风控

 

相信大家或多或少都遇到过某些网站提示你正在使用代理，无法使用某些服务的情况，除了通过最基础的ip判断，还有哪些手段可以检测到我们正在使用代理？本期就来给大家盘点以下四种检测代理的类型，分别是代理ip自身问题、网络行为异常问题、代理配置不当问题、系统环境不符问题

视频开头我们通过这个网页简单的进行了代理检测，估计大部分使用代理的朋友都被检测出来了，因为这个网页调整到了最严格的检测状态，稍微有点代理特征就把你标记为代理用户，为了更直观的展示，我们可以访问这个网页获取更详细的代理检测手段，当前我的代理环境多项检测都被标红，说明检测出了代理特征，绿色部分表示未检测出代理特征，可以说我的代理环境非常糟糕，如果这种状态去运营tiktok或者登陆网银之类风控等级很高的网站，大概率会死的很难看，接下来就来带大家一步步搞定各项检测让他变成一片绿

事先声明，任何网站都不可能公布自家检测代理的方法，我这里仅仅是为了让大家了解各种理论可行的检测方式，事实上很少有网站会做这么严格的限定，可能你要访问的网站只会检测其中的一两项，甚至可能只需更换ip就行了，所以不一定非要全绿才能正常使用，而且实际上你也很难做到全绿，有些检测手段很难绕过且不同手段存在关联，容易按下葫芦起了瓢，再者由于大家使用的代理工具、代理配置以及操作系统都不一样，导致检测结果和解决方法也不一样，我不可能每种情况都给大家做演示，只能简单讲一下绕过检测的方法，具体在你的环境下该如何解决需要你自行研究，希望大家能够理解
另外如果你是小白用户，感觉很麻烦难以搞定，可以看视频最后给大家介绍的即简单又究极的解决方法

首先第一类是代理ip本身的问题，也就是你用的代理ip本身就被该网站屏蔽了，这是最常用的检测手段，我们通过代理访问该网站的时候，首先是你家宽带运营商分配给你的住宅ip3.3.3.3连接了代理ip6.6.6.6，由代理ip帮我们访问这个网站，所以这个网站看到的ip是这个节点的ip6.6.6.6，这个blocklist检测项显示红色，就表示当前我使用的代理ip存在于这个网站的黑名单中，如果你是使用机场节点，或者使用价格便宜，更换ip门槛很低的vps自建节点，以及被很多人当住宅ip用的伪住宅ip，很有可能在黑名单列表，因为这种ip是很多人一起用的，你不知道别人用这个ip干过什么事，比如搭建公共代理，批量注册，发送垃圾邮件，钓鱼诈骗等滥用行为，然后这个ip就会被各大ip数据库公司收集到黑名单列表里，而这个检测网站调用了ip数据库，通过比对发现你的ip在黑名单列表里，于是就判断你正在通过代理访问，点击这里可以看到更详细的信息，这里的isproxy为true，就表示这项检测查出了你正在使用代理访问网站，依据就是你的ip在黑名单里，可以细分为以下几项，isvpn为false表明这个ip不是vpn的出口ip，主要是检查市面上比较大型的vpn商家，比如ExpressVPN、NordVPN、Surfshark等，第二项为true就表示这是代理，第三项tor为false就表示这不是tor节点，至于什么是tor节点我在暗网那期视频讲过，最后就是这给ip是不是被人滥用了，比如发送垃圾邮件钓鱼诈骗等行为，显示true就说明近期有过这种行为，总之就是这个ip不干净，如果你只是用这种ip访问谷歌或者youtube之类的对风控不是很严格的网站可能没什么影响，顶多让你输入验证码，不会阻止你正常使用，而如果是tiktok、facebook、paypal之类对风控要求较高的网站可能会导致你的账号出问题。另外很多网站都提供了ip黑名单查询，比如我们常用的ipinfo，也可以看到ip是否是代理，各家公司的数据库都不一样，检测结果也不同，存在误报的情况，但如果多个平台检测都显示ip不干净那大概率就是不干净。这种情况唯一的解决办法就是换一个没被拉黑的ip，不在黑名单里自然就解决了这个检测，不过也只能代表你用的ip不脏，众所周知我们的代理ip都是在购买vps的时候由商家分配的，如果这个商家的主要业务就是卖vps的，那么在datacenter测试这一栏将会标红，说明负责分配这个ip的商家主要从事数据中心托管业务，也就是公司类型为hosting，点击这里查看更多信息，此项被标记为代理，原因就是因为我们用的这个代理ip是数据中心托管的ip，判定依据就是ip对应的公司主营是hosting托管业务，虽然下面的asn显示isp，但还是被标记为代理，
hosting的ip最显著的特点就是容易获取，我们在vps商家购买的大部分都是这种类型，要绕过这项检测的话就需要找类型不是hosting的商家购买vps，比如类型为business或者isp的商家，不过很少有网站会做这么严格的限制，限制范围太广了会影响自家正常业务
这两项检测是ip本身的问题，只能通过换ip或者vps商家解决

第二类是网络行为异常的检测，顾名思义就是和在没有代理的情况下网络行为不太一样，比如这项延迟测试被标红，详情可以看到被检测出了代理，
主要检测tcp连接和websocket连接的延迟，这个网站的服务器位于美国，在没有使用代理的情况下，我访问网站是直接从中国连接美国的服务器，首先建立tcp连接，假设延迟为150ms，然后建立ws连接，同样假设延迟为150ms

而如果使用美国节点访问这个网站，我首先需要连接到美国的节点，假设tcp延迟是150ms，这个美国节点会帮我们访问网站，所以会和这个网站建立tcp连接，由于地理位置很接近，假设延迟为5ms，接着我这台电脑会发起ws连接，数据来到美国节点耗时150ms，再由美国节点转发给网站耗时5ms，所以建立ws连接总共耗时155ms，而建立tcp连接只记录美国节点到网站的耗时，也就是5ms，网站只能看到是节点服务器在和他进行通信，正常情况下tcp和ws的连接延迟不可能相差这么多，当差值过大就会被标记为代理，这就是该延迟检测的原理
这里就是进行多次tcp连接和ws连接后的延迟，tcp的延迟在70ms徘徊，最小值为70，这是美国节点到美国网站的延迟，下面是websocket延迟，最低延迟是250ms，这个延迟是我这台电脑经过美国节点到这个网站的延迟，由于相差过大，于是被判定为使用了代理

要绕过这项检测，我们需要尽量缩小差值，也就是将节点和网站之间建立tcp连接的延迟拉长，并且缩短我们到节点的延迟，最简单的做法就是改变节点和网站之间的物理距离，比如我现在使用香港的节点，不需要任何处理就能直接就绕过了这项检测， 香港节点到美国网站的tcp延迟是211，我的电脑到香港节点的延迟大概20ms，所以从我的电脑经过香港节点到美国网站的ws延迟为233ms，由于二者的差值较小所以并没有检测出代理
有些朋友会讲，那我一定要用美国节点咋办呢？那确实不好办，所以开头也说了，有些检测很难绕过。
接下来的网络解析也属于网络行为异常，当前判定为代理，主要有两项检测，第一个是通过dns解析行为来判断，第二个是通过能否从非标端口加载脚本来判断，当前是因为dns解析异常导致被判定为代理
该网站会随机访问一个不存在的域名，众所周知访问网站之前会先进行dns解析获取域名对应的ip地址，当dns解析一个不存在的域名时，正常情况下会立即返回空的解析，访问的报错信息是dns解析错误，而不正常的情况就像现在这样，等待3秒后访问的报错信息是超时，说明这个不存在的域名却分配到了ip，并且访问这个ip超时了，通过这个异常行为来判定存在代理，我个人认为有点牵强。
正常情况下大家应该都是绿色的正常检测结果，因为即使是fakeip也能正常处理空解析不会超时，我这里只是为了给大家演示效果故意让他变红的，但有个例外是小火箭的配置模式会导致访问超时，而代理模式就可以正常访问，两种模式的最终结果都是走代理，按理来说不应该出现不同的测试结果，具体原因不明，小火箭用户可以试试

第三类是代理配置不当泄漏本机或者上游ip导致被判定为代理，正常情况下，这个网站应该只能知道我们正在使用的代理ip地址，但由于不当的代理配置，导致本机的ip也被网站知道了，当发现你访问网站用的ip和本机暴露的ip不一致的时候，就判断你在使用代理，最常见的就是webrtc泄漏本机ip，关于webrtc泄漏我在udp那期教程详细介绍过，感兴趣的朋友可以回看，简单来讲，webrtc是通过udp传输的，如果你使用的代理配置只将tcp数据交给节点处理，而udp数据通过直连发给对应的服务器，毫无疑问udp通信将会暴露我们的真实ip地址，通过webrtc检测到了我们的ip是16结尾，也就是用来进行udp通信的ip是16，而我们访问网站实际用到的ip是12结尾，也就是用来进行tcp通信的ip是12，正常情况下tcp通信和udp通信用的ip是一样的，当发现二者ip不匹配时，就会被标记被代理
如果你是使用系统代理模式或者在浏览器安装代理插件的模式都无法将udp流量交给节点，网站会获取到你的真实ip，并将你标记为代理用户，这种情况你可以通过安装浏览器插件来屏蔽webrtc通信，而如果你是使用软路由或者tun模式接管系统全局流量，正常情况下udp流量就会交给节点处理，除非你手动关闭了udp代理，这样情况不需要额外操作，tcp通信和udp通信都是使用同一个节点ip，就能直接绕过webrtc检测了，当然你的机场节点可能存在多个落地ip导致被检测出了代理，以没有泄漏你本机ip为准
除了直接泄漏本机ip，也可能通过其他方面的泄漏来判断存在代理，比如颇具争议的dns泄漏检测，关于这个话题我是做的最多的而且也讲的非常清楚了，详细内容可以回看这期视频，此处我们不讨论如何防止敏感网址泄漏给不可信的dns提供商，只简单介绍dns泄漏检测的工作原理
我们在访问检测网站之前，会先发起dns请求获取网站的ip地址，当我们确定网站需要使用代理的时候，就应该将获取该网站ip的dns交给节点处理，由节点帮我们处理dns请求，代理检测网站可以知道是哪个dns服务商对数据进行了处理，当发现是同样在美国的dns提供商处理的，就表示没泄漏
但代理配置不当的话，就会将dns请求交给了国内的dns提供商处理，代理检测网站发现你是美国的用户，但是为什么会用中国的dns服务？显然是不合理的，于是将你标记为代理，要解决这个问题的话确实比较麻烦，需要具体情况具体分析，并不是像有些人说的开全局就不会泄漏了，可以在我频道搜索dns泄漏相关视频，由于篇幅原因本期不做介绍
另外从该网站的前端源码也能看到dns泄漏的检测项，但是目前没有实施，可能是还没有完成或者关闭了，因为换成任播dns提供商就不好判定代理了

最后第四类就是系统本身环境暴露了代理特征，比如tcp/ip指纹，众所周知是节点负责帮我们访问网站，也就是节点通过三次握手和网站建立tcp连接，网站收到节点的握手数据包，由于各操作系统建立连接的默认参数不同，所以检测网站可以通过tcp数据包的序列号、flag标志位和滑动窗口大小等信息来判断和自己建立连接的是什么操作系统，最简单的比如我们同时ping windows系统和linux系统，两个系统的ttl默认值是不同的，可以看到目前被判定为了代理，这里是可能是某个系统的概率，数值越大则表示概率越高，其中chromium os的数值最大，说明节点服务器是chromium系统的概率最高，而我当前是使用mac系统访问这个检测网站，当二者不一样的时候，就会被标记为代理，下面这些就是tcp建立连接时的参数，通过这些参数计算出是chromium系统的概率最高
要绕过这种检测方式，我们可以通过插件修改浏览器的useragent，改成对应的目标系统即可，因为该网站获取你用的是什么操作系统就是通过http请求中附带的useragent，但这治标不治本，如果是在app里进行检测的话我们就没辙了，当然你也可以在和你本地对应的系统上自建节点，比如将节点搭建在windows系统上，本地也用windows系统连接，或者将节点搭建在linux系统上，本地使用linux系统连接，但本地是ios的话就没办法了，毕竟没有ios的vps购买

另外还有时区问题，目前被检测出来代理，原因是本机的时区是上海，而节点是香港的ip，用香港的ip上网，时区应该也是香港的，虽然他们都是utc+8，但不是同一时区，所以还是被标为代理，解决这个问题比较简单，可以使用浏览器插件或者直接将系统时区改成和节点ip地理位置一样，就可以绕过这项检测了，除此之外还有专门针对浏览器指纹的检测，在之前的这期视频中详细介绍过，感兴趣的朋友可以回看
至此所有的代理检测就都绕过了，而一开始就是绿色的这三项，最后一项是http协议头中的代理信息，我们用的代理是不可能会有的。至于这两项检测意义不明，前端也看不出是怎么检测的，我也从来没有被标红过就不讲了

我想补充的是，虽然页面已经全绿了，但一定会有无法绕过的代理特征，不可能完全隐藏掉，只不过这个网页没有检测罢了，如果你真的不想暴露任何代理特征，可以使用windows远程桌面，给vps安装windows桌面系统，通过远程桌面的方式连接vps，这样我们是远程操控这台windows电脑，相当于桌面镜像，并没有使用代理，自然也就检测不出任何代理特征了

翻墙新姿势, 全场景通吃的xhttp传输协议快速上手

 XHTTP文档：https://github.com/XTLS/Xray-core/discussions/4113

 
安装3x-ui
bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh)

安装v2rayN
https://github.com/2dust/v2rayN/releases

上下行分离 (xhttp+tls+cdn)：

{
  "downloadSettings": {
    "address": "a.abc.com", 
    "port": 443, 
    "network": "xhttp", 
    "security": "tls", 
    "tlsSettings": {
      "serverName": "a.abc.com", 
      "allowInsecure": false
    }, 
    "xhttpSettings": {
      "path": "/b5fa9725", 
      "mode": "auto"
    }
  }
}


上下行分离 (xhttp+reality)：

{
  "downloadSettings": {
    "address": "1.1.1.1", 
    "port": 443, 
    "network": "xhttp", 
    "xhttpSettings": {
      "path": "/b5fa9725", 
      "mode": "auto"
    },
    "security": "reality", 
    "realitySettings": {
          "serverName": "yahoo.com",
          "fingerprint": "chrome",
          "show": false,
          "publicKey": "Vhl8jHMxoC-ycZ-TfUKa4xqlQnAyWVYZ2GxrYYC6fgY",
          "shortId": "3f",
          "spiderX": "/"
        }
  }
}



2023年5月份，v2ray添加了一个叫meek的传输协议，其最大优势在于可以将我们的代理数据封装在正常的http流量里进行传输，看上去就好像在访问普通的网站，由于其属于正常的http流量，自然就能通过cdn传输，这也是meek主要的应用方式，配合某些支持域前置的cdn，可以实现几乎不可能被墙的代理方式，但meek的传输效率太低导致网速很慢，无法当主力使用，属于是防失联的备用方案

在同一天，有人希望能将meek添加到xray中实现更通用的过cdn方式，但对比meek分包上行+分包下行的传输方式，xray作者rprx表示可以通过更好的分包上行+流式下行的传输方式提升网速，同样能过cdn，所以并没有添加对meek的支持，此事不了了之，时间来到一年后的2024年6月份，另一位开发者根据当时提出的分包上行、流式下行开发了新的传输协议splithttp，同样是为了过cdn，对比meek下行传输效率有了质的提升

举个例子，假设电脑想要访问谷歌，浏览器的请求来到代理工具，如果是使用普通的tcp传输，会直接通过tcp连接将字节流发送到节点服务器，也就是流式上行，节点服务器收到数据后会帮我们访问谷歌，谷歌返回的内容来到节点服务器，节点再通过tcp连接将字节流返回给代理工具，也就是流式下行，代理工具再将数据交给浏览器，这是常见的代理传输流程，此处我们省略了上层ss协议对数据进行加解密的过程。

假设使用meek进行传输，浏览器访问谷歌的请求来到代理工具，meek会将请求分成一个个小的http数据包，发送到meek节点，也就是分包上行，节点会将数据重新拼装成完整的http请求，然后帮我们访问谷歌，谷歌返回的内容来到节点服务器，节点将内容分成一个个小的http数据包，代理工具通过不停的找节点要数据获取到所有数据包，也就是分包下行，接着将数据重新拼装成完整的http响应，交给浏览器，这样就通过meek传输完成了一次代理访问。

再假设使用splithttp进行传输，浏览器访问谷歌的请求来到代理工具，上行和meek一样，splithttp会将请求分成一个个小的http数据包，发送到节点服务器，也就是packet-up分包上行，节点将数据重新拼装成完整的http请求，然后帮我们访问谷歌，谷歌返回的内容来到节点服务器，节点将数据封装成支持流式传输的不定长chunk响应返回给代理工具，不需要和meek一样不停找节点要数据，接着将数据交给浏览器，这样就通过splithttp传输完成了一次代理访问，这就是三者在传输上的主要区别，可以看出流式传输要比分包传输效率高得多，至于分包的目的是为了兼容cdn，而splithttp在2024年下半年通过不断更新迭代，目前已经实现了stream-up流式上行过cdn，还支持字节填充、多路复用、上下行分离等特性，并将该协议更名为xhttp，这些特性都有什么作用请大家自行查阅作者发布的文档，有非常详细的解释，这里就不花时间介绍了，直接进入喜闻乐见的搭建环节，演示搭建xhttp+reality，以及xhttp+tls套用cdn，并且实现上下行分离，另外这个新的传输协议功能很多，相应的配置参数也非常多，好在大部分参数都有默认值不需要配置，所以搭建起来也比较简单，本期教程的目的在于让大家先用起来，尽量使用默认参数，你要自己调的话请参考作者发的文档，网址我会放在视频下方的说明栏。

虽然官方不推荐3xui，但为了大家能尽快上手，我这里还是使用大家最容易接受的web面板进行搭建，首先使用这条指令一键安装3xui，web面板明文的问题我就不再强调了。进入xui后台地址，登陆之后来到入站列表，添加一个入站，先以xhttp+reality为例，端口建议使用443，安全设置为reality，点击这里设置密钥，最后在这里设置一个适合你vps的网站域名，这些都是以前讲过的搭建reality节点步骤，没有什么区别，如果此时点击添加，就创建了一个普通的reality节点，现在我们要使用xhttp传输协议，则还需要进一步设置，将传输改成xhttp，在这里随便设置一个路径，比如把用户id前面一小段复制过来，其他都按默认值不需要改动，最后点击添加，这样一个vless+xhttp+reality节点就搭建好了，非常简单，对比普通的reality节点，这个节点还能有xhttp的传输特性，比如字节填充，多路复用，上下行分离等，点击这里可以扫码二维码导入代理工具，或者直接点击二维码复制节点链接，由于xhttp是新协议，很多代理工具都还不支持，电脑端可以使用v2rayN，安卓端可以使用v2rayNG，现在v2rayN也支持mac系统了，在这里下载适合你系统的版本，这就是v2rayN在mac端的界面，还是熟悉的配方，第一次打开可能是英文版，在这里切换为中文，mac版不包含内核，需要点击这里更新，勾选xray和geo数据库，最后点击更新即可，如果无法在线更新，也可以在设置中找到存储位置，手动下载内核到这个目录里，复制刚才搭建的节点链接，粘贴到v2rayN中即可导入，测试真链接，有延迟说明节点可以正常使用，接着就可以和windows端一样，配置好系统代理之后就能使用这个xhttp+reality节点进行科学上网了，可以看到访问ip是节点的ip，通过直连使用xhttp就完成了，另外目前普通的reality节点就很稳了，如果你用不到xhttp的那些特性，也可以使用普通的reality节点，并不一定要追新。

和meek一样，xhttp最初的目的主要是为了过cdn，所以再来演示一下使用xhttp过cdn，配置方式和我们以前讲过的ws过cdn是一样的，添加一个入站，先来搭建一个裸vless+xhttp，类似以前搭建的vmess+ws，端口建议设置为80，如果80端口有其他用途的话就随便设置一个，比如6666，传输改成xhttp，随便设置一个路径，最后点击添加，这样一个vless+xhttp就搭建好了，非常简单。
接着套cdn，以cf为例，我有两个域名，先使用第一个121343，来到dns设置，添加一条解析记录，名称随便设置，比如a，填入节点的ip地址，代理状态要勾选，点击保存，接着将tls加密模式设置为灵活，也就是浏览器到cf进行tls加密，cf到vps不进行加密，可以点击这里进行修改，选择自定义tls，改成灵活后保存即可，接着来到网络页面，启用grpc即可实现流式上行，最后来到规则下的origin rules，如果你刚才搭建的裸xhttp节点用的是80端口就可以省略这一步操作，点击创建规则，随便给个名称，跟着视频操作，在这里填入刚才设置的dns解析域名，目标端口设置为重写，在这里填入裸xhttp节点所使用的端口6666，此时就算是配置好了，复制这个裸xhttp节点链接，导入代理工具，将地址改成刚才设置dns的域名，端口改成443，传输层安全设置为tls，如果你要优选ip的话，就把域名填入sni，然后在地址这里输入你优选后的ip即可，都是以前讲过的内容这里就不浪费时间演示了，最后点击确定，测试真链接，有延迟说明可以正常使用，这样就算是套上cdn了，和以前ws套cdn几乎是一样的。

接下来讲点不一样的，使用xhttp实现上下行分离，其作用在文档中也有说明，主要是给gfw上强度，可能需要一段时间才能体现其价值，我们刚才搭建的这个cdn节点上下行都是使用a.121343.xyz，也就是代理工具会和a.121343.xyz建立上下行两个连接，浏览器访问谷歌的请求会通过上行连接来到cdn，cdn将其转交给a.121343.xyz这个域名绑定的ip，也就是我们的节点，节点再帮我们访问谷歌，谷歌返回的数据来到节点，节点通过刚才建立的下行连接将数据返回给代理工具，从而实现代理访问谷歌。

而如果我将下行配置为b.888005.xyz，代理工具会和a.121343.xyz建立上行连接，和b.888005.xyz建立下行连接，由于ab两个域名都是绑定的节点ip，所以最终都是指向我们的节点，浏览器访问谷歌的请求会通过上行连接来到cdn，cdn将其转交节点，节点再帮我们访问谷歌，谷歌返回的数据来到节点，节点通过刚才建立的下行连接将数据返回给代理工具，从而实现上下行分离代理访问谷歌。

接下来进行搭建操作，计划使用a.121343.xyz上行，使用b.888005.xyz下行，如果你只有一个域名的话，也可以使用a.121343.xyz上行，使用b.121343.xyz下行进行验证，或者即使是同一个域名，也可以配置不同的优选ip进行上下行分离，上行的121343域名刚才已经配置好了，接下来为下行配置888005的域名，先添加一条解析记录，名称设置为b，ip地址同样填入vps的ip，代理状态要启用，其他设置都一样，就不再重复说明了，设置好之后先复制一个节点出来进行测试，将地址改成刚才设置的域名b.888005.xyz，将sni删掉，测试真链接，有延迟说明已经生效了

接下来实现a.121343.xyz上行，b.888005.xyz下行，需要用到这段下行配置，在这里填入优选后的ip，如果不需要优选的话就直接填入域名，端口和节点保持一样是443，servername就是下行要用到的域名，把xhttp中的path路径改成和节点一样的即可，这样就算是配置好了，将其全选复制，双击编辑上行域名为121343的节点，点击这里添加额外参数，将配置粘贴上去，意思是下行使用888005的域名，点击确定，注意节点修改后配置会跑到列表最下面，测试真链接，有延迟说明没有问题，这样我们就实现了在套用cdn的情况下实现上下行分离，你可以用wireshark抓个包看看分离效果

最后演示上行使用cdn，下行使用reality直连，这种配置场景适合下行直连速度比较快的vps，比如gia线路，套cdn的话太浪费了，但又害怕直连会导致ip被墙，就可以用这个方式，先把刚才添加的xhttp+reality节点删掉，跟着视频操作搭建一个vless+vision+reality节点，传输是普通的tcp不是xhttp，最后点击添加，这就是一个普通的reality节点，没有什么特别的，将其导入代理工具，可以正常链接，接着给这个reality节点设置回落，重新编辑该节点，3xui有个问题是开了reality之后就看不到fallback回落的设置项，所以先把安全改成无，就会出现回落设置项，添加一个回落，将目标设置为6666，也就是裸xhttp节点所使用的端口，接着将安全改回reality，fallback配置项又看不见了，但是我们刚才的设置已经生效了，只是界面上不显示，最后点击修改，添加回落之后这个reality节点就能当下行了，同样将a.121343.xyz当上行，将刚才的下行配置删掉，使用这段reality下行配置，这里填入vps的ip地址，以及reality使用的端口443，这里填入裸xhttp的path路径，这里改成你的reality节点配置，如果不会手动改的话，可以借助v2rayN，右键刚才添加的reality节点，将客户端的配置复制到剪贴板，粘贴到文本编辑器，往上找到reality的配置，复制大括号这整段，将这里的替换掉，接着全选复制，粘贴到cdn节点的下行配置，最后点击确定，这样就实现了通过cdn进行tls上行，通过直连使用reality下行了，有延迟说明可以正常使用。

现在的效果相当于，代理工具会和cdn建立上行连接，cdn会将数据转交给节点，和reality节点建立下行连接，从防火墙的角度来看我们在访问yahoo，也就是我们在节点中设置的sni，当reality节点收到建立连接的请求时，发现自己看不懂这些数据，因为解开reality之后，里面是裸xhttp数据，而这个是vless+vision+reality节点，根本就无法处理xhttp数据，我们之前讲过，当vless不认识这个数据的时候，而我们又设置了回落，就会将其转交给回落中设置的端口6666，于是这个搭建在6666端口的裸xhttp节点将会收到该数据，而这个节点能看懂数据，因为本来就是发给他的，于是成功建立了连接，所以表面看我们是和reality建立下行，但实际上是和裸xhttp建立下行，上下行连接建立之后，浏览器访问谷歌的请求会通过上行连接来到cdn，cdn将其转交给节点，节点再帮我们访问谷歌，谷歌返回的数据来到节点，节点通过下行连接将数据返回给代理工具，从而实现上行cdn，下行直连reality访问谷歌。

------------------------------

XHTTP: Beyond REALITY

 

XHTTP: Beyond REALITY

开发简述：2024 年中，@mmmray @ll11l1lIllIl1lll 等人基于 @RPRX 所述的“分包上行、流式下行”原理及实现细节开发出了 SplitHTTP，首次实现了不牺牲下行效率的同时穿透绝大多数支持 HTTP 的中间盒，并首次大规模实现了 QUIC H3 过 CDN，开启了一个崭新的时代，浏览器转发 Broswer Dialer 支持、减少特征的 header padding、控制复用的 XMUX、解锁 REALITY 也相继被安排上。随后 @RPRX 接手开发，实现了真正的上下行分离并更名为 XHTTP，比如上下行可以分别是 IPv6 CDN H3、IPv4 REALITY H2（源 IP 都可以不同），这下又开启了一个崭新的时代，紧接着开发了不牺牲上行效率的流式上行 stream-up 模式、可以分享全部细节配置的 extra 方案，并给 stream-up 模式加上了默认的 gRPC header 伪装，实现了 H2 流式上行过 CDN，取代了传统的 gRPC 传输层，当初发现这也行就不会有它了，最后将 HTTP 传输层作为 stream-one 模式并入 XHTTP，使其也拥有了 header padding、XMUX、gRPC header 伪装等特性。至此，我们有了完全体 XHTTP：各种姿势穿透中间盒、上下行分离、丝滑的 XMUX 等应有尽有，XHTTP 全场景通吃的时代正式到来。

原为导剪版文档，不小心写成了文章。这篇文章旨在帮助你透彻地理解 XHTTP 的原理、设计，以便更好地使用它。

如果你要捐助 Xray 项目、收藏 NFT，相关介绍在文末，感谢支持！

快速上手指南

别看 XHTTP 的参数较多，其实都调好了默认值，如果你只是想用 XHTTP 的话，只需遵循六步：

1. 无论是 TLS 还是 REALITY，一般来说 XHTTP 配置只需填 path，其它不填即可
2. 服务端支持 QUIC H3 的话，客户端 alpn 选 "h3" 即可使用 QUIC
3. CDN 优选 IP 的话，客户端 address 填 IP，serverName（SNI）填域名即可
4. 连不上 CF 的话，启用 CF 面板内的 gRPC 支持
5. 无法穿透 Nginx 的话，把 Nginx 的 proxy_pass 改为 grpc_pass
6. 无法穿透其它 CDN 或反代软件的话，建议 mode 选 "packet-up"，兼容性最强

XHTTP 默认有多路复用，延迟比 Vision 低但多线程测速不如它，除非测速前设了 "maxConcurrency": 1，参考 XMUX 小节。

CF 会掐断下行 100 秒无实际数据的 HTTP，代理长连接需在应用层面保活，比如 SSH 需在 sshd 设置 ClientAliveInterval。

这篇文章可以当增强版文档用，它基本上涵盖了关于 XHTTP 你想要了解的所有内容，对每个参数都有解释，文末也有一份涵盖了所有参数的配置示例，并且标注了每个参数的使用场景，如果你对哪个参数不清楚，文内搜索参数名即可找到该参数的详细解释。

两个底层逻辑

正如 REALITY 可以伪装成别人的网站，反审查的根本逻辑就是增加审查者执行封锁时的“附带伤害”，使审查者不敢贸然封锁，我当年看好 TLS 以及 TLS 上流量的时序、长度特征混淆也是同理。多年经验告诉我们 GFW 不会永久封锁大型 CDN 的整个 IP，否则会波及太多常规网站，那么对于 XHTTP，我们最初的目标就是把它隐藏在众多各种各样的 CDN 后面。然而 CDN 为了防止源站遭受攻击，除了有特殊支持的 WS、gRPC 外，一般会缓存完整个 HTTP 请求再发给源站，许多 HTTP 中间盒默认也是这样的行为。据此，Tor 的 Meek 协议把往返流量包装为了一个个 HTTP 请求以穿透这些中间盒，但速率惨不忍睹，因为它没有采用 XHTTP 的“流式下行”。什么是“流式下行”呢？想象一下你正在一个网站上下载一个很大的文件，CDN 没击中缓存于是回源拿，但显然它不太好像上行一样先缓存完整个文件让你干等，而是源站发来多少数据，CDN 就即时转发给你，这就是 XHTTP “流式下行”的基础，也保证了最重要的下行速率可以拉满。至于上行，出于兼容性考虑，XHTTP 首先实现的是“分包上行”，即把上行流量包装为一个个 POST 请求，它的效率显然会打折扣，但好在对于一般的代理需求而言上行流量极少。此后我加了“流式上行”，并且我们发现加上 gRPC header 伪装后还能 H2 流式上行穿透 CF，而我几轮优化”分包上行“后速率甚至直追”流式上行“。

顺便谈一下最近又比较火的套 CDN 是否属于“滥用”的问题：显然不支持流式上行的 CDN 其本意并非让你用来搭建代理服务，但我们为了对抗 GFW，不断探索、开发、利用尽可能多的新路是合理且必要的，是不得已而为之，且增加审查者的“附带伤害”就是要求我们混入“正常”服务，这也是不可避免的。举个最简单的例子：哪天 IP 白名单了而 CDN 的 IP 在里面，你用还是不用？反审查这一领域并不适用现实世界的一些规则，这么简单的道理却一直都有人想不明白。 如果还是没想通，那像 WebSocket 这样的传输层现在仅为了套 CDN 而存在，作为开发者可以删掉它，作为用户可以建议开发者删掉它，以自身的实际行动来证明“滥用 CDN”并不只是为了眼红攻击 Xray 这一为满足某些病态心理的日经无聊行为而找出的又一个借口罢了，与此同时身体却很诚实，与此同时不难窥见，有些人的虚伪本质已经暴露无遗。

PACKET-UP

这一小节技术细节太多，非开发者可以只看粗体部分。

对于 XHTTP 兼容性最强的“分包上行、流式下行”，即 packet-up 模式，我们是这样设计的：

1. 客户端 POST /yourpath/sameUUID/seq 以发送上行数据：

   • UUID 是随机生成的，等下启动下行时的 UUID 与它相同，以便服务端关联，若服务端未在 30 秒内成功关联，将终止会话
   • seq 从 0 开始，必须发完上一个 POST 的 body（但无需等响应）再发下一个
   • 多个 POST 有小概率乱序到达服务端，服务端会按 seq 进行重组，默认最多缓存 30 个，超限断连
   • 注意 UUID 和 seq 都设计在 path 里而非 query string，以避免遇到奇怪的问题

2. 客户端 GET /yourpath/sameUUID 启动下行，服务端响应头包含：

   • X-Accel-Buffering: no 以告知中间盒禁用缓冲
   • Cache-Control: no-store 以告知中间盒无需缓存
   • Content-Type: text/event-stream 以伪装成 server-sent events（兼容性更好，可以设置 noSSEHeader 以关闭）
   • 若为 HTTP/1.1 还需包含 Transfer-Encoding: chunked，H2/H3 则不需要

3. 为了避免浏览器转发 Browser Dialer 遇到跨域限制，服务端针对所有 GET、POST 的响应头都会包含：

   • Access-Control-Allow-Origin: *
   • Access-Control-Allow-Methods: GET, POST

4. 为了解决 HTTP 请求头和响应头的固定长度特征：

   • 客户端发的 request header 均默认包含 Referer: ...?x_padding=XXX...（放 Referer 是为了防止 Browser Dialer 产生不必要的 OPTIONS 请求），默认长度为 100-1000，每次请求随机，服务端默认会检查它是否在服务端允许的范围内
   • 服务端发的 response header 均默认包含 X-Padding: XXX...，默认长度为 100-1000，每次响应随机
   • 这便是我多次提及的 header padding，对应设置项为 xPaddingBytes
   • 请求头的 padding 改为放到 Referer 由 @rPDmYQ 提出，选用 XXX 也是，X 在 huffman encoding 中为 8 bit

分包上行、Referer: ...?x_padding=XXX... 会产生较多、较长的日志，你可以在反代软件中设置不记录它们。

此外，和 Xray 的其它传输层一样，服务端也接受 X-Forwarded-For header 以取得客户端的真实 IP，也会依据服务端设置的 host 来检查客户端发来的 host（个人建议是没事别设，毕竟已经隐藏在 path 后面了）。

以上就是 packet-up 模式的最简化、必要流程，不过此时还有个小问题：如何具体实施、限制 POST 请求？有三个专属参数：

• scMaxEachPostBytes：客户端每个 POST 最多携带多少数据，默认值 1000000 即 1MB，该值应小于 CDN 等 HTTP 中间盒所允许的最大值，服务端也会拒绝大于该值的 POST
• scMinPostsIntervalMs：仅客户端，基于单个代理请求，客户端发起 POST 请求的最小间隔，默认值 30 毫秒
• scMaxBufferedPosts：仅服务端，基于单个代理请求，服务端最多缓存多少个 POST 请求，默认值 30 个，超限断连

“基于单个代理请求”的意思是每个代理请求各自计数、互不影响，即使它们在同一条 H2 / H3 连接内，这便是 sc 即 sub-connection 的含义。为了减少指纹，前两个值可以设为范围的形式，比如分别为字符串 "500000-1000000"、"10-50"，每次随机。这些参数都可以通过 extra 下发给客户端，文末有说明。此外值得一提的是，Xray 最新版优化了 packet-up，速率甚至直追 stream-up，主要利好 QUIC H3 过 CDN。

H1 / H2 / H3

既然我们有了几乎能穿透所有 HTTP 中间盒的 packet-up 模式，让我们来讨论一个有趣的东西：QUIC H3 过 CDN，即当初 SplitHTTP 那个崭新的时代，理解这一小节对于灵活使用 XHTTP 尤为重要。

很多 HTTP 中间盒的一个特性就是会进行 HTTP 版本的转换，比如 CDN、Nginx 会将收到的 H3 流量转为 H1 或 H2 流量回源，也就是说我们的 XHTTP 服务端可以仅监听 H1 和 H2，无需监听 H3，但 XHTTP 客户端却可以使用 H3。

这也是 XHTTP 服务端的默认行为：仅监听 TCP 端口并处理 H1 和 H2 流量。 当启用 TLS 并在 alpn 处仅设置一个元素 "h3" 时，服务端将仅使用 quic-go 监听 UDP 端口并处理 H3 流量，但是目前不建议你这样做，而应将 XHTTP 隐藏在真正的 Nginx、Caddy 后面以减少指纹特征，这也是 XHTTP 相较于其它 QUIC 类代理的重要优点之一，另一个当然是能过 CDN。 此外 H3 的拥塞控制为应用层实现，理论上你可以修改这些反代软件的 QUIC 拥塞控制算法并编译，以实现有些人想要的暴力发包。

对于 XHTTP 客户端：

1. 启用 TLS/REALITY 时，默认使用 H2，否则使用 HTTP/1.1
2. 启用 TLS 时，若 alpn 仅有 "http/1.1" 则使用 HTTP/1.1（但 Xray 并不会允许它修改 uTLS 浏览器指纹伪装）
3. 启用 TLS 时，若 alpn 仅有 "h3" 则使用 quic-go H3
4. 不过当你使用 Browser Dialer 时，具体的 HTTP 版本就由浏览器决定了（整个 tlsSettings 都会失效）

如果你要确认 Xray 客户端实际使用的 HTTP 版本、host，以及 XHTTP mode、上下行分离等信息，将日志调至 "info" 级别即可。

代理的 QUIC H3 过 CDN，至少 XHTTP 是首个大规模实现的，开了条新路，毕竟有的地区、有的运营商对 H3 审查不严，不过也有的会 Q 死。即使后来我们开发了 stream-up 模式并发现了加上 gRPC header 伪装就能穿透 CF，也只作用于 H2，看来这个崭新的时代的含金量还在不断上升。

XMUX

既然我们提到了 H2 和 H3，就不得不提它们的多路复用：均为 0-RTT，区别是 H3 没有 H2 的 TCP 队头阻塞问题，并且支持连接迁移，客户端换网也不会断。那么经常研读 RFC 的朋友就会问了：如何具体控制它们的多路复用？我们设计了一个简洁而强大的接口，即 XMUX：

• maxConcurrency：每条 TCP/QUIC 连接中最多同时存在多少代理请求，连接中的代理请求数量达到该值后 core 会建立新的连接，以容纳更多的代理请求。XMUX 全为 0 时该项默认值为 "16-32"，每次随机。

• maxConnections：最多同时存在多少条连接，连接数达到该值前每个新的代理请求都会开启一条新的连接，此后 core 会开始复用已有的连接。该值与 maxConcurrency 冲突，只能二选一。默认值 0，即不限制，支持填写范围，每次随机。

• cMaxReuseTimes：一条连接最多被复用几次，复用该次数后将不会被分配新的代理请求，将在内部最后一条代理请求关闭后断开。默认值 0，即不限制，支持填写范围，每次随机。

• hMaxRequestTimes：@xqzr 发现 Nginx 默认最多允许每条 TCP/QUIC 连接累计承载 1000 个 HTTP 请求，XMUX 全为 0 时该项默认值为 "600-900" 取随机，否则该项默认 0 即不限制。该项基于 HTTP 请求计数，一般来说 stream-one 只产生一个 HTTP 请求，stream-up 是两个，packet-up 则是 N 个。该项计数不严谨，且 Golang 的 GET 请求有自动重试，故不建议顶格填写，那些 CDN 什么的要试出来。其中 packet-up 上行循环 POST 时若超过该值会自动切换到另一个 TCP/QUIC 连接，占它一个 reuseTimes 但不占 concurrency。 其实按 XMUX 的三项默认值，stream-* 不会超限，就 packet-up 会超，而它是 H3 的默认 mode，所以新增该项又主要是利好了 H3。

• hMaxReusableSecs：@xqzr 发现 Nginx 默认最多允许每条 TCP/QUIC 连接被复用一个小时，XMUX 全为 0 时该项默认值为 "1800-3000" 取随机，否则该项默认 0 即不限制。TCP/QUIC 连接持续该时间后将不会被分配新的 HTTP 请求，将在内部最后一个 HTTP 请求关闭后断开。其中 packet-up 上行循环 POST 时若超过该值会自动切换到另一个 TCP/QUIC 连接，占它一个 reuseTimes 但不占 concurrency。

• hKeepAlivePeriod：H2 / H3 连接空闲时客户端每隔多少秒发一次保活包，默认 0，即 Chrome H2 的 45 秒，或 quic-go H3 的 10 秒。它是 XMUX 里唯一不允许填范围（该项取随机才是特征）且允许填负数（比如填 -1 关掉空闲保活包）的项，建议留 0。

XMUX 提供的这些参数可以组合出各种用法，比如多线程测速前需要设 "maxConcurrency" 1，而“无限”复用可以设 "maxConnections" 1。即使你懒得研究也没事，当这些值全为 0 时就会取到上面写的三个默认值，相当于隔段时间就换个新的 H2/H3 主连接，相当丝滑，不会有 gRPC、HTTP 传输层始终复用同一条连接导致的“断流”体验。同样，这些参数都可以通过 extra 下发给客户端。

注：全不填也相当于全为零，会取到三个默认值，但若填了任一项，其它项就没有默认值了，全都要自己填，除前两项外其它项均可同时填。

此外，使用 XHTTP 时不要启用 mux.cool，并且新版 Xray 服务端已有检查，只接受纯 XUDP。

关于 XMUX 的默认值，一些摘录：

• 我特地选了两个在 TLS 外不太能看出来的选项即 maxConcurrency 加 cMaxReuseTimes（而不是 maxConnections 加 cMaxLifetimeMs），并且这两个选项的默认值都是 range 取随机，最大程度上消除了潜在特征。
• 我选择 maxConcurrency 而不是 maxConnections，就是为了防止连接数成为 fixed pattern，当然如果你喜欢后者也可以手动设置

• XMUX 和 Nginx 的计数对象不同，maxConcurrency 和 cMaxReuseTimes 都是基于“被代理连接”计数的，只有 stream-one 会产生一个 HTTP 请求，而 stream-up 一个上行一个下行是两个，packet-up 则是 N 个
• 不过我不确定 stream-one 会不会在某些情况下自动多产生一个 HTTP 请求，还有我觉得追求一条连接复用到底没有太大的意义，因为你是运营商的话你也会限速、清理旧的连接，不然资源都被旧连接慢慢占完了，所以 XMUX 的默认参数就是限制复用+定期换连接

文章下方还有讨论一些 Nginx 参数。

STREAM-UP/ONE

终于轮到 XHTTP 的另一个重要模式了：“流式上行、流式下行”的 stream-up，顾名思义这种模式的上行也是流式的，从而不会牺牲上行效率。 它本来是为 REALITY 而开发的，直到我们发现加个 gRPC header 伪装 H2 就能穿透 CF（需要在面板中开启 gRPC 支持），并且 Nginx 等反代软件的支持也不错（Nginx 推荐 grpc_pass，简单省事），所以 mode 默认值 "auto" 的行为是：

• 客户端：TLS H2 时 stream-up，REALITY 时 stream-one（有 downloadSettings 时 stream-up），否则 packet-up
• 服务端：默认同时接受三种模式，若设为具体的模式就是仅接受它，"stream-up" 是例外，它还接受 stream-one

stream-up 比 stream-one 兼容性好一些，有群友说 CFT 开了流式上行就能用 stream-up，但还得再开个选项才能用 stream-one（可能是 SSE 伪装的锅？），还看到有个 CDN（忘了啥名字）用 stream-one 会被严重限速，但用 stream-up 不会

它们的实现方式是（非开发者可以跳过）：

• 对于 stream-up，把 packet-up 的分包上行改为流式的 POST /yourpath/sameUUID 即可，也有 Referer: ...?x_padding=XXX...
• 对于 stream-one，POST /yourpath/ 即可，响应即为下行，双向流式，请求头、响应头均有 header padding
• 注意 stream-one 如果填 /yourpath，实际请求的是 /yourpath/，若末尾没有 / 会自动补上
• 上行均默认有 Content-Type: application/grpc 以伪装成 gRPC（可以设置 noGRPCHeader 以关闭）
• 下行的服务端响应头与 packet-up 的 1 完全一致，stream-one 会出现以 SSE 回应 gRPC 的奇观，若遇到问题可尝试 noSSEHeader

#4113 (comment) 的相关测试发现 CF 会掐断下行 100 秒无实际数据的 HTTP，导致 stream-up 的上行方向被掐断，所以这个 PR 为服务端添加了 scStreamUpServerSecs，默认值 "20-80" 取随机，服务端每隔这段时间就会发 xPaddingBytes 个字节以保活

可以设置 "scStreamUpServerSecs": -1 以关闭该机制，此时服务端甚至不会及时发 response header，和以前版本的行为相同

那么经常使用 gRPC 的朋友就会问了：stream-up 比 gRPC 传输层有什么优势呢？

• 前者无需任何 gRPC 库，性能更好
• 前者的下行流量是独立的 GET 请求，不会受到 CDN 对 gRPC 的流量限制
• 前者还有 header padding、XMUX、上下行分离 等增强，且已经引入了 extra 机制，所有参数均可分享，更成熟

当然，XHTTP 相较于 WebSocket、HTTPUpgrade 的优势，除了“没有 ALPN 为 http/1.1 的显著特征”外，相信你都看到这里了，心里也早已有了答案，我就不一一列举了，主要是太多了也不好列。

上下行分离

压轴登场的当然是又一个崭新的时代：上下行分离。 我们大概知道，现在 GFW 针对 TLS in TLS 等流量特征的检测是基于单条连接，那么如果我们把上下行拆分到不同的审查系统，比如上行跑 IPv4 的 TCP，下行跑 IPv6 的 UDP，GFW 就会一时反应不过来。而由于 XHTTP 服务端仅基于 path 中随机生成的 UUID 关联上下行，packet-up 和 stream-up 天生就具有真正的上下行分离能力，且由于 XHTTP 可以穿透各种 CDN、可以搭配 REALITY 等，可选姿势也无限多。对于客户端，需要设置 downloadSettings：

"xhttpSettings": {
    "host": "example.com",
    "path": "/yourpath", // must be the same
    "mode": "auto",
    "extra": {
        "headers": {
            // "key": "value"
        },
        "xPaddingBytes": "100-1000",
        "noGRPCHeader": false, // stream-up/one, client only
        "noSSEHeader": false, // server only
        "scMaxEachPostBytes": 1000000, // packet-up only
        "scMinPostsIntervalMs": 30, // packet-up, client only
        "scMaxBufferedPosts": 30, // packet-up, server only
        "scStreamUpServerSecs": "20-80", // stream-up, server only
        "xmux": { // h2/h3 mainly, client only
            "maxConcurrency": "16-32",
            "maxConnections": 0,
            "cMaxReuseTimes": 0,
            "hMaxRequestTimes": "600-900",
            "hMaxReusableSecs": "1800-3000",
            "hKeepAlivePeriod": 0
        },
        "downloadSettings": { // client only
            "address": "", // another domain/IP
            "port": 443,
            "network": "xhttp",
            "security": "tls",
            "tlsSettings": {
                ...
            },
            "xhttpSettings": {
                "path": "/yourpath", // must be the same
                ...
            },
            "sockopt": {} // will be replaced by upload's "sockopt" the latter's "penetrate" is true
        }
    }
}

可以看出，downloadSettings 其实就是一套全新的 streamSettings，但是多了类似于 VLESS 出站中的 address 和 port 以指向另一个入口。显然其中 network 必须为 "xhttp"（不可省略），security 可以为 "tls" 或 "reality"。sockopt 项也可被分享，但接收方可以在上行的 sockopt 里将 penetrate 设为 true 以覆盖下行，适合打 mark 的情况。除该特例外，上下行分离时下行配置是完全独立的，不会继承上行的任何配置，而且比如，即使上下行均未填 XMUX 从而取默认值时，它们分别在 range 内 roll 出的确定值也是相互独立、无关的，这样随着时间的推移，上下行的复用完全不对称，切换主连接的时间点也不同，反分析效果更好。因为 GFW 若要对上下行分离动手，“主连接发起的时间点相同”肯定是最重要的切入点，所以以后 XHTTP 还会允许一开始就以不同的时间点发起上下行连接。

其实如果你套了 CDN，甚至不需要修改服务端配置就可以玩转上下行分离，比如你可以优选出一个 IPv4 跑 TLS H2，再优选出一个 IPv6 跑 QUIC H3。而且 CDN 基本都支持“同域域前置”，比如上行 serverName 填 "a.example.com"，下行 serverName 填 "b.example.com"，上下行 host 均填 "c.example.com"，实现外部 SNI 看起来也不同，当然如果你本来就有两个域名就更好了。如果你没有任何域名的话，也可以开两台 VPS、开两个 REALITY 玩上下行分离：无论是 CDN 加反代，还是 REALITY 加回落，只要最终以同一 path 抵达同一 VPS 上的同一 XHTTP 入站即可。总之由于 XHTTP 到处都能用，可随意搭配出来的组合是无限的，唯一的问题是脑洞够不够大。

比如上下行分离问世后，很多人的用法其实是把上行分给去程优的线路、把下行分给回程优的线路，这样也挺实用的。

比如你可以再给上行设 "maxConnections": 1，给下行设 "maxConcurrency": 1，实现上行的少量数据都走同一条底层连接，而下行的大量数据分散到不同的底层连接上，同时兼具反审查、低延迟、高速度，有点像 Switch，搭配 Vision Seed 食用效果更佳。

上面贴出了一份涵盖了所有参数的配置示例，主要是为了让大家知道每一项应该写在哪，并说明一下前文中没怎么解释的参数：

• extra 是 host、path、mode 以外的所有参数的原始 JSON 分享方案，当 extra 存在时，只有该四项会生效。且分享链接中只有这四项，GUI 一般也只有这四项，因为 extra 中的参数都相对低频，且应当由服务发布者直接下发给客户端，不应该让客户端随意改。
  补充说明：“下发”的意思是“人去下发”，就是服务发布者写好 extra 后整个放进分享链接，客户端直接作为自己的 extra 就可以用。

• host 的行为与 Xray 其它基于 HTTP 的传输层一致，客户端发送 host 的优先级为 host > serverName > address。服务端若设了 host，将会检查客户端发来的值是否一致，否则不会检查，建议没事别设。host 不可填在 headers 内。

如果你要确认 Xray 客户端实际使用的 HTTP 版本、host，以及 XHTTP mode、上下行分离等信息，将日志调至 "info" 级别即可。

Beyond REALITY

去年初我回归并写了秒天秒地秒空气的 REALITY，一举解决了多个痛点，然后就天天泡夜店没怎么管了，连文章都鸽到了现在还没完成，XUDP UoT Migration 更可惜，去年文章快写完了都没发，不知不觉 REALITY 已悄然成长为直连主力，经常能看到 XX 被封了下面的评论是推荐换 REALITY，口碑是有目共睹的，甚至因为过于稳定，这里都没以前热闹了。虽然 Xray 也为其它 transports 做出过大量优化、改进，但 XHTTP 是第一个 Xray 原生的传输层，第一个就整了波大的，当你看完这篇文章，也清楚 XHTTP 可以和 REALITY 一起用：

Beyond REALITY 的意思并非是取代 REALITY，而是流行程度超越 REALITY。毫不夸张地说，正如 Xray 一贯的风格，XHTTP 的出现使得其它基于 HTTP 的传输层全部黯然失色，这就是 XHTTP 全场景通吃的时代。它将会比上一个成功的协议 REALITY 更加流行，因为 XHTTP 的特性就已经决定了它的覆盖面会更广。

最后，希望 XHTTP 的出现能够给大家带来一点小小的震撼，正如 Xray 历史上多次做到的那样：变革、推陈出新，始终是 Xray 的信仰。

from  https://github.com/XTLS/Xray-core/discussions/4113

（ https://lcuwx2016.github.io/xtls/config/transports/xhttp.html）

给你的节点加上暗网功能，完全免费的三重"链式代理"，前置代理+tor+后置代理的配置方法

 
安装x-ui：

bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh)
安装tor：

(apt update && apt install -y tor) || (yum update -y && yum install -y tor) || (dnf update -y && dnf install -y tor)
或者使用官方源：https://support.torproject.org/zh-CN/apt/ 

https://support.torproject.org/zh-CN/rpm/

检测是否连上tor网络：

https://check.torproject.org/?lang=zh_CN

https://community.torproject.org/onion-services/

手搓配置
前置代理+tor网络

{
  "api": {
    "services": [
      "HandlerService",
      "LoggerService",
      "StatsService"
    ],
    "tag": "api"
  },
  "burstObservatory": null,
  "dns": null,
  "fakedns": null,
  "inbounds": [
    {
      "allocate": null,
      "listen": "127.0.0.1",
      "port": 62789,
      "protocol": "dokodemo-door",
      "settings": {
        "address": "127.0.0.1"
      },
      "sniffing": null,
      "streamSettings": null,
      "tag": "api"
    },
    {
      "allocate": {
        "concurrency": 3,
        "refresh": 5,
        "strategy": "always"
      },
      "listen": null,
      "port": 54701,
      "protocol": "shadowsocks",
      "settings": {
        "clients": [
          {
            "email": "pziqletm",
            "method": "",
            "password": "KMW2djHGMlEooAHNiB4FSnxG78oUFC2I6rNBF7MVeFU="
          },
          {
            "email": "toruser",
            "method": "",
            "password": "ExLav0MGff+rF4UgWsk56Q1bg3+RM0+2nRyQWUNsp+8="
          }
        ],
        "ivCheck": false,
        "method": "2022-blake3-aes-256-gcm",
        "network": "tcp,udp",
        "password": "Ur88nrUnNSkOBYFaec/wB+3dY5Kx65nQVEiw3q5VyOw="
      },
      "sniffing": {
        "destOverride": [
          "http",
          "tls",
          "quic",
          "fakedns"
        ],
        "enabled": false,
        "metadataOnly": false,
        "routeOnly": false
      },
      "streamSettings": {
        "network": "tcp",
        "security": "none",
        "tcpSettings": {
          "acceptProxyProtocol": false,
          "header": {
            "type": "none"
          }
        }
      },
      "tag": "inbound-54701"
    }
  ],
  "log": {
    "access": "none",
    "dnsLog": false,
    "error": "",
    "loglevel": "warning",
    "maskAddress": ""
  },
  "observatory": null,
  "outbounds": [
    {
      "protocol": "freedom",
      "settings": {
        "domainStrategy": "AsIs",
        "noises": [],
        "redirect": ""
      },
      "tag": "direct"
    },
    {
      "protocol": "blackhole",
      "settings": {},
      "tag": "blocked"
    },
    {
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "localhost",
            "port": 9050,
            "users": []
          }
        ]
      },
      "tag": "tor"
    }
  ],
  "policy": {
    "levels": {
      "0": {
        "statsUserDownlink": true,
        "statsUserUplink": true
      }
    },
    "system": {
      "statsInboundDownlink": true,
      "statsInboundUplink": true,
      "statsOutboundDownlink": false,
      "statsOutboundUplink": false
    }
  },
  "reverse": null,
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "inboundTag": [
          "api"
        ],
        "outboundTag": "api",
        "type": "field"
      },
      {
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "blocked",
        "type": "field"
      },
      {
        "outboundTag": "blocked",
        "protocol": [
          "bittorrent"
        ],
        "type": "field"
      },
      {
        "domain": [
          "domain:onion"
        ],
        "outboundTag": "tor",
        "type": "field"
      },
      {
        "outboundTag": "tor",
        "type": "field",
        "user": [
          "toruser"
        ]
      }
    ]
  },
  "stats": {},
  "transport": null
}


前置代理+tor网络+后置代理：

{
  "api": {
    "services": [
      "HandlerService",
      "LoggerService",
      "StatsService"
    ],
    "tag": "api"
  },
  "burstObservatory": null,
  "dns": null,
  "fakedns": null,
  "inbounds": [
    {
      "allocate": null,
      "listen": "127.0.0.1",
      "port": 62789,
      "protocol": "dokodemo-door",
      "settings": {
        "address": "127.0.0.1"
      },
      "sniffing": null,
      "streamSettings": null,
      "tag": "api"
    },
    {
      "allocate": {
        "concurrency": 3,
        "refresh": 5,
        "strategy": "always"
      },
      "listen": null,
      "port": 54701,
      "protocol": "shadowsocks",
      "settings": {
        "clients": [
          {
            "email": "pziqletm",
            "method": "",
            "password": "KMW2djHGMlEooAHNiB4FSnxG78oUFC2I6rNBF7MVeFU="
          },
          {
            "email": "toruser",
            "method": "",
            "password": "ExLav0MGff+rF4UgWsk56Q1bg3+RM0+2nRyQWUNsp+8="
          }
        ],
        "ivCheck": false,
        "method": "2022-blake3-aes-256-gcm",
        "network": "tcp,udp",
        "password": "Ur88nrUnNSkOBYFaec/wB+3dY5Kx65nQVEiw3q5VyOw="
      },
      "sniffing": {
        "destOverride": [
          "http",
          "tls",
          "quic",
          "fakedns"
        ],
        "enabled": false,
        "metadataOnly": false,
        "routeOnly": false
      },
      "streamSettings": {
        "network": "tcp",
        "security": "none",
        "tcpSettings": {
          "acceptProxyProtocol": false,
          "header": {
            "type": "none"
          }
        }
      },
      "tag": "inbound-54701"
    },
    {
      "allocate": {
        "concurrency": 3,
        "refresh": 5,
        "strategy": "always"
      },
      "listen": null,
      "port": 19276,
      "protocol": "vmess",
      "settings": {
        "clients": [
          {
            "email": "jq8fcm9a",
            "id": "58cb22ea-bf6e-424c-83f8-1b6c24c27f23"
          }
        ]
      },
      "sniffing": {
        "destOverride": [
          "http",
          "tls",
          "quic",
          "fakedns"
        ],
        "enabled": false,
        "metadataOnly": false,
        "routeOnly": false
      },
      "streamSettings": {
        "network": "tcp",
        "security": "none",
        "tcpSettings": {
          "acceptProxyProtocol": false,
          "header": {
            "type": "none"
          }
        }
      },
      "tag": "inbound-19276"
    }
  ],
  "log": {
    "access": "none",
    "dnsLog": false,
    "error": "",
    "loglevel": "warning",
    "maskAddress": ""
  },
  "observatory": null,
  "outbounds": [
    {
      "protocol": "freedom",
      "settings": {
        "domainStrategy": "AsIs",
        "noises": [],
        "redirect": ""
      },
      "tag": "direct"
    },
    {
      "protocol": "blackhole",
      "settings": {},
      "tag": "blocked"
    },
    {
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "localhost",
            "port": 9050,
            "users": []
          }
        ]
      },
      "tag": "tor"
    },
    {
      "protocol": "vmess",
      "settings": {
        "vnext": [
          {
            "address": "45.77.242.212",
            "port": 19276,
            "users": [
              {
                "id": "58cb22ea-bf6e-424c-83f8-1b6c24c27f23",
                "security": "auto"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "none",
        "sockopt": {
          "addressPortStrategy": "none",
          "dialerProxy": "tor",
          "penetrate": false,
          "tcpFastOpen": false,
          "tcpKeepAliveInterval": 0,
          "tcpMptcp": false
        },
        "tcpSettings": {
          "header": {
            "type": "none"
          }
        }
      },
      "tag": "vmess-jq8fcm9a"
    }
  ],
  "policy": {
    "levels": {
      "0": {
        "statsUserDownlink": true,
        "statsUserUplink": true
      }
    },
    "system": {
      "statsInboundDownlink": true,
      "statsInboundUplink": true,
      "statsOutboundDownlink": false,
      "statsOutboundUplink": false
    }
  },
  "reverse": null,
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "inboundTag": [
          "api"
        ],
        "outboundTag": "api",
        "type": "field"
      },
      {
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "blocked",
        "type": "field"
      },
      {
        "outboundTag": "blocked",
        "protocol": [
          "bittorrent"
        ],
        "type": "field"
      },
      {
        "domain": [
          "domain:onion"
        ],
        "outboundTag": "tor",
        "type": "field"
      },
      {
        "outboundTag": "vmess-jq8fcm9a",
        "type": "field",
        "user": [
          "toruser"
        ]
      }
    ]
  },
  "stats": {},
  "transport": null
}

教授访问暗网就是在助纣为虐？确实由于其不受监管，不法分子会利用暗网来进行非法活动，但这并不是tor的问题，tor的初衷是为了更好的保护用户隐私，曝光美国棱镜监视计划的爱德华斯诺登就曾多次公开推荐使用 Tor 来保护隐私和匿名通信，而且暗网也只是tor的一个应用，只不过很多教程都直接把tor网络和暗网画上等号，导致很多人对tor网络存在误解，事实上tor不仅可以用来访问暗网，也能访问表网，还能用来代理ssh、ftp等其他tcp流量，比特币钱包还能针对tor节点进行单独配置，我们熟悉的singbox也支持tor出站，但默认编译的版本没有嵌入tor，需要自己编译或者从外部载入

接下来就来教大家脱离洋葱浏览器直接使用tor网络，事先声明，教程仅供技术交流学习探讨，不提倡使用tor网络从事任何违法活动，虽说tor网络可以完美隐匿你在网络上的行踪，但你的数据会因为你的各种不当操作而从tor网络中泄漏出去，请勿以身试法

开始之前再简单讲讲tor网络的工作原理，你可以把它看做是一个免费的三层链式代理，当我将访问谷歌的请求发送给tor的时候，他会从tor网络中随机选择三个中继节点并建立链接，然后通过握手协商获取每个节点的共享密钥，首先使用节点3的密钥对数据进行加密，然后在这个基础上再使用节点2的密钥对数据进行加密，最后使用节点1的密钥对数据进行加密，加密后的数据将会发给tor网络里的中继节点1，这个节点也称为守卫节点，由于数据你是直接发给他的，所以他是唯一知道你ip地址的节点，守卫节点拿到数据后，会使用他的密钥对数据进行解密，获取到了经过节点2密钥加密的数据，由于节点1并没有节点2的密钥，所以无法解密，节点1无法看到里面的内容，解密之后的数据会发给节点2，节点2会使用他的密钥进行解密，获取到了节点3加密的内容，同样的，节点2无法看到被节点3加密的内容，同时数据是节点1发给他的，所以他不知道你的真实ip，解密后的数据将会发给节点3，节点3使用密钥进行解密，得到了你的意图是访问谷歌，于是帮你访问谷歌，谷歌会认为是节点3在访问他，节点3是出口节点，他知道你要访问谷歌，但不知道你的真实ip，因为数据是从节点2发给他的，在这种情况下如果想追踪你是谁，在访问哪？就必须同时控制这三台中继节点，并且tor每隔十分钟就会更换节点，也可以随时手动切换节点，在这个由志愿者组成的去中心化网络想要追踪你几乎是不可能的

为了屏蔽本地系统差异可能出现的各种问题，教程选择将tor网络搭建在节点上，首先我们需要搭建一个普通的节点，以xui面板为例，在vps上执行这条指令安装xui面板，这些用到的信息我会放在视频下方的说明栏，接着访问连接进入面板，来到入站列表，我这里视频演示就随便搭建一个ss节点，将这个节点导入代理工具，测一下延迟，有延迟说明可以正常使用，接着我们就可以启用这个节点进行科学上网了，这台vps的ip尾数是212，访问ping0查询一下节点ip，ip地址确实是212，此时这就是一个普通的ss节点，并不能访问暗网，暗网必须要先连接tor网络才能访问，可以访问这个网址来检测一下，网页提示我们没有使用tor，也可以在这里获取一些暗网网址，比如访问暗网版bbc，就会显示无法访问

接下来让这个节点支持访问暗网，首先使用这条指令安装tor，安装完成后稍等片刻，执行lsof -i:9050指令，如果和我一样返回了这个tor的进程，说明tor已经安装好了并且成功启动了，默认情况下tor会在9050端口开启socks代理，也就是你通往tor网络的入口，只要将你需要进入tor网络的流量交给9050端口就行了，利用xray的路由功能可以轻松实现这个目的，回到xui面板，来到xray设置，在出站规则下添加tor的入口，协议选择socks，随便给个标签，地址和端口就填写tor监听的入口，填localhost或者127.0.0.1都可以，点击添加，接着来到路由规则页面添加一个路由，在domain这里输入domain:onion，outbound tag选择刚才添加的tor出站，点击添加，点击保存，并且重启xray，如果你和我一样点击重启后卡住了，那是因为我们一边正在使用这个节点，一边又要重启这个节点，类似自己把自己抬起来，不符合常理，所以你可以先切换到其他节点再点击重启，或者直接在vps上执行x-ui restart，此时就算是配置好了，

这样通过节点访问onion域名的流量都会进入tor网络，首先刷新检测网页，提示我们没有连接tor，因为这个检测网页是org的表网域名，并不是暗网，所以数据并没有发送到tor网络里，接着尝试刷新onion结尾的暗网域名，就成功的通过谷歌浏览器进入了暗网版bbc，不需要使用洋葱浏览器，不过这样的隐匿性没有使用洋葱浏览器好，因为谷歌可能会收集你的访问数据，也就是知道访问了哪些暗网网站，洋葱浏览器不会收集这些信息，这里还列举了一些其他的暗网网站，都是正规的，同样也都可以正常访问了，虽然速度有点慢，现在的配置相当于访问暗网的流量会进入tor网络，访问其他表网还是直接使用vps，但如果你希望访问表网也通过tor网络，则还需要进一步设置， 回到xui，给这个ss节点再添加一个客户端，将电子邮件设置为toruser，点击添加，将其导入代理工具，目前他还只是一个普通的节点，来到xray设置，出站我们刚才已经添加好了tor节点，添加一条路由规则，在user这里填入刚才设置的电子邮件toruser，出站选择tor，意思是不管你是访问表网还是暗网，还是诸如ssh、ftp之类的需要被代理的流量，只要使用这个节点，数据全都会通过tor网络代理，点击添加，然后保存并重启xray，此时就算是配置好了，接着我只要切换到toruser的节点，所有代理数据都会通过tor网络，再来检测一下，可以看到显示我们的数据经过了tor网络，不过网页会提醒我们没有使用洋葱浏览器，如果要更强的隐私保护则推荐使用洋葱浏览器，这个尾数198的ip就是洋葱网络的出口节点，respect，包括其他表网检测到的也将会是tor节点的ip，相当于对外隐藏了我vps的ip地址，由于用tor网络来干坏事的人太多，ip风险程度爆表100%是预期效果，等会我也会教大家通过后置代理解决这个问题，表网都是用tor那暗网更是没问题了，可以正常访问， 这就是将所有流量导入tor网络的配置方式，如果你只希望访问暗网才通过tor网络就用刚才配置的第一个ss节点

有些朋友不想使用面板，希望自己手搓配置实现，我会将对应的配置文件提取出来，供大家手搓参考，不过毕竟手搓的受众比较小，我将继续使用xui面板来为大家做演示

安卓手机就以nekobox为例，将节点导入nekobox，选中节点并开启代理，有延迟，接着打开浏览器，可以通过tor网络访问表网谷歌，并且可以看到出口节点的ip已经发生了改变，上期也讲过tor网络的节点会定时自动更换防止被追踪，但由于ip太脏了要进行烦人的人机验证，建议我们跳过这个环节，尝试访问暗网版brave，提示无法加载，因为域名无法解析到ip，这是因为暗网域名只能在tor网络中路由，并没有对应的ip地址，由于手机默认使用的是需要在本地进行dns的tun模式，而dns找不到暗网对应的ip，于是就报错了，这种情况下需要开启fakeip模式，进入nekobox的设置，在下面找到启用fakedns的选项，也就是fakeip，启用他，此时的onion域名将会交给节点处理，本地不会解析，而节点收到onion域名将会根据路由转发到tor网络中，应用之后重新访问暗网，就可以成功通过普通浏览器访问暗网网站了，这就是安卓的配置方法

刚才电脑用的是socks代理模式，socks不需要在本地进行dns解析，可以直接将暗网域名交给节点处理，如果你要开tun的话需要将onion域名配置为fakeip模式，至于啥是fakeip三言两语讲不清，可以回看这期经典老番，这里就不再啰嗦了

至于ios的话我使用safari和chrome尝试了一下，发现他们不管是不是fakeip，压根就不处理onion域名，可能是系统限制，所以只能访问表网无法访问暗网

刚才我也说了tor网络的出口节点对于表网来说无一例外，注意是无一例外全都是高风险的ip，比如访问这个网站查看ip的评分，可以看到是信任分为0的高风险ip，即使出口ip又发生了改变，甚至可以在这里看到检测出了这是tor节点，包括滥用、攻击、代理等点亮的小红灯，用这个ip访问表网的话很多网站都会被限制，所以接下来教大家通过后置代理解决这个问题，先看操作，在面板上再随便添加一个节点，比如vmess，复制节点链接，来到xray设置下的出站规则，点击添加出站，将刚才复制的节点链接粘贴上去，点击右边的图标解析，点击添加出站，接着重新编辑该节点，启用sockopts，dialer proxy选择tor，点击确定，来到路由规则，修改刚才toruser节点的出口，将其改成刚才添加的vmess节点，点击确定，最后点击保存并重启xray，这样就算是配置好了

此时的效果相当于，我通过ss节点访问谷歌，由于使用的是toruser的节点，而toruser的路由是从vmess出去，于是数据将通过vmess进行加密发送，但是vmess节点设置了通过tor节点代理，于是这条经过vmess加密的数据会发送到tor网络，经过tor的三层代理来到了vmess节点，也就是他自己，使用vmess解密后发现是访问谷歌的，于是通过直连帮我们访问了谷歌，对于谷歌来讲和他通信的ip是这台vps，而不是高风险的tor出口ip，这就是后置代理的通信过程

尝试查询ip，可以看到落地是使用vps的ip，而不是tor网络的出口ip，虽然这个ip的纯净度也不咋地，检测页面显示没有使用tor网络，那是因为落地并不是tor出口ip，但是我们中间确实使用了tor网络，暗网也是可以正常访问的，有些朋友可能有疑问，入口是vps的ip，出口又是vps的ip，那为啥不直接访问，还要到tor网络里转一圈？为了降低网速吗？有没有用先放一边，你就说这操作六不六吧，当然也可以套个cdn啥的，这里就不再拓展了，大家自行发挥

另一种场景是使用不同的vps实现后置代理，比如我这里有一个住宅ip的socks节点，但是我不想让这个socks节点知道我的前置代理ip，就可以通过tor网络连接，在面板里添加一个socks出站，将这个住宅ip的信息填进去，同样启用sockopts，dialer proxy选择tor，点击添加，来到路由规则，你可以单独添加一个规则，或者修改toruser节点，将这个用户的出口改成住宅ip的socks代理，最后保存并重启xray，此时再来检测ip落地就是干净的美国住宅ip了，前置代理是vps，落地的后置代理是住宅ip，住宅ip不知道数据是从前置代理发过来的，由于ip比较干净就不会像tor出口一样被表网各种阻挡了

最后讲一下怎么搭建暗网网站，非常简单，在vps上修改这个torrc的配置文件，搜索hidden，找到这个位置，将这三行前面的#号注释删掉，第一行是数据保存的目录位置，第二和第三行表示端口映射，访问暗网的80端口就相当于访问本机的80端口，你可以使用nginx在这台vps的80端口上搭建一个网站，我就直接转发xui的端口做演示了，复制xui使用的端口，粘贴到这里，先复制这个路径，等会要用，修改完成后保存退出，然后执行这条指令重新运行tor，接着使用这条指令查看这个路径下的hostname，这个就是我的暗网域名，复制到浏览器中访问，如果发现没有反应的话，看看是不是浏览器自动加上了https，我的xui是没有配置tls的，所以要改成http，再次访问网页返回一片空白，因为缺少了路径，将xui的路径加上，就能成功进入暗网版的xui面板了

如果你想贡献vps到tor网络中当中继节点，请自行查阅相关文档，tor的配置参数非常多，可以实现更细致的设定，比如手动切换链路，屏蔽某些地区的节点或者只连接某些地区的节点，感兴趣的朋友可以自行研究。

TikTok注册运营全过程分享，硬件设备选择、网络环境伪装、住宅IP和机房IP的区别、视频质量对自然推流的影响，跨境电商媒体运营风控预防指南

 

跨境电商严格的风控机制一直是个令大家头疼的问题，动不动就限流乃至封号，让前期的努力都打了水漂，现在的风控策略不可能通过单一变量就能得出具体结论，一定是多维度动态调整的监测体系，你使用的设备、网络的环境、账号的行为、甚至是发布的内容质量等等，都可能成为风控的一环，并且针对不同时期可以动态调整风控的阈值，有些小心翼翼做的好好的账号也突然被风控了，于是将其归咎为玄学，但计算机的世界不存在玄学，背后都是算法 + 规则在运行，之所以觉得玄学，只是因为平台的检测维度比我们预想的更多。

本期我就从零开始注册一个tk账号，实际发布作品来观察账号具体的表现，并在此过程中告诉大家有哪些可能被检测的因素，需要先声明的是我将尽量以大多数人都能执行的方式做演示，不会在各个环节都用最严格的伪装，因为要绕过所有检测是不现实的，比如我们只要使用代理就一定有能被检测的特征，解决方法就是直接肉身飞到当地去不用代理，但这样就没有意义了，我和大家一样并不清楚tk具体的风控机制，只能根据我收集到的反馈进行合理的推测，尽量把技术上可以实现但不一定会检测的因素也告诉大家，供大家参考，或许其中有解决玄学之道，另外虽然本期演示的是tk平台，但视频中提到的风控注意事项是通用的，所以不管你是做tk还是ins、facebook等其他平台都可以参考借鉴

首先我使用的设备是2019年发布的第七代国行ipad，ios系统版本为18.5，用它是因为这是我自用的闲置设备，可以保证之前没有用来做过tk，如果你要在二手平台购买，尽量找个人闲置设备，不要买工作室退下来的设备，如果对方之前是做tk矩阵的话，设备肯定注册过大量账号，tk会结合硬件信息通过算法给每台设备生成唯一id，相当于是设备的指纹，大量注册的行为或许已经让设备被tk限时拉黑了，你再买来做tk的话可能出现限流甚至是在注册阶段就被秒封，有些朋友包括很多卖tk课程的非常天真的以为刷机后就能当新设备用了，这也太不把ByteDance放眼里了，刷机升级系统或者抹机恢复出厂设置并不能改变硬件信息，所以会被认定为是同一台设备，包括有些进阶用户知道越狱或者root之后可以通过一些改机工具修改设备的硬件参数，真要检测的话同样有手段，另外目前市面上有些云手机号称可以用来做tk运营，其实大多数就是个安卓模拟器，有商家也给我发了推广邀请，表示他们是使用真机硬件进行模拟的，但我经过测试发现还是无法和真机比较，当时正好处于tk风控比较严格的时期，在确认代理ip没问题的情况下依然存在注册秒封的情况，虽然他们说发现问题所在并从技术层面解决了，但这仅仅是解决了注册秒封的问题，后续运营是否存在其他风控问题不好说，总之对于设备目前我只推荐大家使用物理真机，建议使用苹果设备，如果你想用安卓，不建议使用国行安卓手机，系统经过深度定制有些功能被阉割了，可以使用谷歌的piexl或者海外版本的安卓手机，另外我用的是国行ipad，也就是专供中国大陆市场的苹果设备，理论上来讲tk是可以检测到我用的是国行版本，比如我们熟悉的代理工具singbox就是通过能否显示台湾的emoji来判断是否为国行设备，非常的欢乐，但据观察tk似乎并没有做这么严格的检测，大部份做海外tk的用户也都是二手国行设备，所以我也用国行设备做演示，当然如果你想伪装更好点，可以购买非国行版本，比如美版有锁机可能还更便宜，另外你还需要注意不要插国内的sim卡，我之前的视频通过抓包给大家验证了tk是会判断sim卡的归属地并通过carrier_region参数发送到tk服务器，如果地区是CN的话就不给你返回视频数据，导致刷不了视频，不过目前的客户端好像没有这个限制，但做运营的话最好还是不要插SIM卡，至于有卡槽却不插卡是否会对账号权重有影响这个就不得而知了，反正有很多人都是不插卡做tk的，你要实在担心的话可以去某宝买一张国外的废卡插上，tk只检测sim卡的归属地并不检测sim卡是否有效，我这没卡槽的ipad就不用关心这个问题了，关于设备的注意事项就讲这么多

接下来讲讲手机系统环境的相关设置，我的是ios18.5，你的可能和我不一样，系统版本差异没有影响，首先在隐私与安全性中关闭定位服务，然后在通用下的语言和地区，将地区修改为你要运营的区域，我就以风控相对严格的美国为例，更改地区之后tiktok app就能正常刷视频了，但为了伪装更好点，语言最好也改成对应地区，点击添加语言，将其改成英语，并将原来的语言移除，最后来到keyboards键盘设置，将简体拼音输入法移除，其他就没什么特殊设置了，做完这些操作之后最好是重启一下设备，另外可以看到我装了一些国内的app，建议你最好别装，尤其是微信支付宝之类的国民级app，虽然在ios系统中普通应用无法直接获取安装的app列表，但从技术上来讲可以通过URL Scheme检测是否安装了某些app，做好以上步骤之后就可以使用外区id在app store中下载tiktok了，下载完成后先不要打开，因为我们还有非常关键的配置代理环境步骤

常见的手机代理环境有两种，一种是直接在手机上安装代理工具，比如我们常用的小火箭，另一种是使用软路由，从技术角度来讲不管是代理工具还是软路由，都能通过对应的方式检测到你正在通过代理访问tk，只是相对来讲软路由不运行在手机里，能检测的手段更少一点，但对小白用户来讲上手软路由的门槛比较高，如果你愿意折腾，可以看我软路由系列教程，考虑到很多做tk运营的并没有使用软路由，我更倾向于tk没有做相关检测，所以就简单一点，选择直接在手机上安装代理工具，以shadowsocket小火箭为例，同样使用外区id在app store中下载，这软件是收费的，不会充值的话可以网上买个共享id

有了代理工具之后，你所使用的节点ip也是非常关键的一环，也是很多朋友最难解决的问题，
原生IP、广播iP、住宅ip、机房ip、ISP、风控值、纯净度等等一堆令人头疼的概念，多数人更愿意花钱买时间，于是催生了很多卖tk节点的商家，你通过购买他的节点访问tk，但他给你的节点是否就一定能用来做tk是要打问号的，而且你根本就不知道商家把一个节点同时卖给了多少人，所以我还是建议你自己搭建节点，这样才能保证节点只有你一个人在用

根据我收集到的多数反馈来看，做tk并不一定非得是住宅ip，用普通机房ip同样可以运营tk，毕竟大部份地区根本就没有真正的住宅ip购买，属于有市无价
我之前也独家分享了怎么寻找并搭建任意地区所谓的tk节点，其实就是普通的机房ip，很多人也都在用这种ip在做tk，动手能力强的看完都能直接当tk节点卖家了

另外我不建议用基础套餐太廉价的vps商家，在跨境运营中这并不是优点，廉价意味着干坏事被清算的代价小，代价小的话爆破、挂马、钓鱼、投毒、DDOS等各路牛鬼蛇神黑灰产就都来了，很快这些ip段就会被各大检测平台拉入黑名单，也就是我们说的ip太脏了，建议避开

当然你如果能获取到真正的住宅ip那肯定是最好的，毕竟机房ip和住宅ip的性质不同，可能会被tk区别对待，比如同一个机房ip注册运营三五个账号就是极限了，而同一个住宅ip可能注册运营三五百个账号都没问题，这是合理的推测并不是瞎说

因为美国作为互联网的发源地，虽然只有 3 亿人口，但却拥有 16 亿个 IPv4 地址，占全球总分配量的 43%，将近一半。而剩下的190多个国家76亿人口分配剩下的20亿个ip地址，这种严重的不平衡导致很多国家和地区不得不依赖 CGNAT 来缓解 IPv4 地址不足的问题，CGNAT实现了同一小区甚至同一街道的宽带用户共用同一个ip，也就是成千上万个用户都是使用同一个ip进行上网，目前大部分家庭都经过了CGNAT处理，也就是我们常说的家里没有公网ipv4地址，而是和其他人共用同一个公网ip，如果说一个公网住宅ip只能注册三五个tk账号，那剩下的几万人都没法用了，全都要被风控，所以合理的推测是住宅ip是可以通过不同设备进行大批量注册tk的，只要操作方式接近真实用户行为，避免在短时间内使用同一设备集中批量操作，当然这里的前提是真正意义上在当地找运营商办理宽带业务的家宽住宅ip，而不是网上廉价的双isp伪住宅ip，经常有人来问我新马泰菲越等东南亚地区的住宅ip推荐，遗憾的是这些地区本身分配到的ip数量就十分有限，更不可能有真正的静态家宽住宅ip公开销售，至少我没有可靠渠道推荐给大家，目前除了ip充裕的美国，我还没有看到其他地区有真正的静态家宽住宅ip公开销售，要么是拨号自动更换ip的动态住宅IP，要么就是标记为双ISP的伪住宅ip，如果你非常幸运在当地有朋友，则可以通过我之前讲的反向代理将他的住宅ip共享给你使用，关于ip就讲这么多，总之有条件的可以想办法获取真正的家宽住宅ip，没有条件的就用干净点的机房ip

由于我有条件，所以选择使用真正的美国AT&T家宽住宅ip，之前我也出视频给大家介绍过，如果你是做美国地区的话可以试试，这家提供的住宅ip确实是在美国当地找ATT运营商办理的家庭宽带，不是托管在机房里的ip，并且IP只给你一个人独享，这是我能向大家保证的，当然价格确实挺贵的，毕竟成本也很高，使用这个连接注册的账号能获得所有订单永久5%的折扣优惠，算是给大家争取的福利，从部分用户反馈的情况来看好的ip确实能提升流量，从复购率来看也能反映这个情况，如果你觉得作品质量高但没有获得足够的自然流量，可以尝试一下。我也期待能收到大家更多的反馈

为了简单一点，我选择这个vless节点的新产品，这个是商家已经搭建好了节点并且通过gia线路进行了中转，导入代理工具就能直接用了，非常省事，如果你想使用其他产品的话可以点击这里查看相关教程，购买后可以在用户后台查看节点的二维码
打开代理工具小火箭，通过扫码将vless节点导入，接着将config改成proxy，然后启用代理，使用浏览器访问ip.cn，看看ip是否是你买的ip，一切准备就绪

接下来就开始运行tiktok，如果你是抹机恢复出厂设置了，可能启动界面和我不一样，我是之前登陆过其他账号，不影响，选择sign up注册账号，你可以直接通过其他账号登陆，也可以手动输入邮箱或者手机号进行注册，随便设置一个生日，
理论上来讲使用手机号注册更好，你可以找一些接码平台获取当地的手机号，想简单一点就和我一样直接使用邮箱进行注册，点击获取验证码，此时有可能会直接提示你账号被封了或者收不到验证码，这种情况需要排查设备或者节点是否存在风控问题
先确认设备之前是否进行过异常操作，开头也说了刷机是没法更改设备指纹，你的设备做过几个tk账号平台是门清的
之前收到一个朋友的反馈说他使用的是自己的闲置设备，能确认以前没有做过tk，但是注册的时候就提示直接被封，这种情况大概率是他的节点问题，我问他用的是什么节点，他说一开始使用共享的vpn节点进行了三次注册全都被封了，于是使用独享住宅ip节点，结果还是注册就秒封
首先他就不应该使用vpn或者机场的节点做tk，ip基本上都不干净，其次被封肯定是设备或者ip有风控问题，不应该连续注册，由于tk平台已经记录了他这台设备的三次异常注册行为，所以之后即使使用没问题的ip进行注册还是秒封，我们可以推测他的设备暂时被tk平台拉黑了，具体什么时候解封或者说会不会被解封就得看平台的风控机制，当然我们还不能确定他的住宅ip就一定没问题，所以我给他使用指纹浏览器在网页上进行tk注册，在相同节点的情况下，使用网页注册可以正常收到邮箱验证码并成功注册，根据这一结论可以合理推测节点没问题， 秒封原因主要是设备之前使用了vpn节点进行注册的异常操作导致的，大家如果遇到这种情况也可以从设备和节点上面找原因。如果确定设备没问题的话再看看是不是节点ip的原因，尝试换个节点再试试，但注意一定不能频繁测试，保险一点最好是间隔24小时

我能确定我这台设备没问题，节点也没问题，很自然的能接收验证码，设置好密码和昵称后就能正常进入tk刷视频了
我进行了一段时间的测试，给大家分享一下时间线
首先是刚注册后随便刷了一会视频，可以正常点赞和评论，但是还不能关注别人，可能是tk防止有人批量注册白号刷粉，注册后的第二天才能关注，期间又随便刷了点视频，前两天没有发布视频

接着第三天发布了该账号的第一个视频，是全球人民都爱看的猫片，素材来自网上随便找的某个混剪视频，我只是将该视频素材的顺序进行了更换，算是做了一定程度的去重防止被认定为搬运，视频发布后的三分钟之内就有人点赞，十分钟内视频播放量350，点赞17个，半个小时内视频播放量大约是650，半个小时后流量下降，之后缓慢的有播放量，24小时后基本上就不会再有自然流量了，最终定格在897，对于一个完全没有粉丝基础的新号，我觉得这个播放量在合理范围内，可能平台对新账号的第一个视频有流量扶持
因为第四天发布的第二个视频播放量定格在300多，也是同样打乱别人视频顺序的混剪方式，可能和视频内容也有关系，没什么亮点，比较寡淡
第五天发布了第三个视频，以同样的方式打乱混剪，但这次发布之后等了2个小时还是0播放，说明视频发布后完全没有自然推流，于是我删了之后重新换了个封面和标题，视频内容没做任何改动再发一次，这次有自然流量，但是明显感觉到流量对比之前是下降严重的，你要说他识别到了是搬运的，但账号检测的时候这个视频又没有问题的，而且第二次发布同样的内容只是换了封面和标题又有点播放量，没法进行归因

第六天发布了第4个视频，改变了一下风格，是从某个抖音视频截取的一小个片段，并对其进行了缩放，视频播放量是475，说明有自然推流
第七天延续了第六天的做法，从某个抖音视频截取一小段，并对其进行缩放，区别在于素材比较久，是别人一年前发布的视频，这次就没那么幸运了， 直接被识别为搬运，播放量同样是很低
第八天又换策略，发布的视频是从多个视频中分别截取一小段拼在一起，333个播放

最后我想看看账号是已经被限制在三四百的播放量，还是说和视频质量有关系，于是我自己花了点时间做了个混剪，没有原创素材且质量一般，但好在这个视频确实得到了一些正反馈，播放量回到了800多，可以明显感觉到，只要你的视频质量好一点，算法自然会多给你推荐，从用户的留存率、点赞和评论等信息来判断是否要继续推流，这个视频也是点赞数最多的，有115个，这些都是真实的用户，没有一点假

以上就是我反馈给大家的真实数据。没有出现随手一拍播放量破百万的奇迹，这种平庸的表现才是常态，我们可以随便刷几个直播视频，能看到在线人数只有个位的直播间，能刷到就证明他的账号有自然推流，这个国外博主没有墙肯定不需要做什么网络设备环境伪装，但她的作品基本上也就几百的播放量，说明这个质量只能匹配这么多的流量，如果你当前的网络环境有自然流量，建议你把精力放在作品的质量上，不要过分关注其他因素