[{"content":"","date":"2026年5月26日","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"2026年5月26日","externalUrl":null,"permalink":"/tags/fail2ban/","section":"Tags","summary":"","title":"Fail2ban","type":"tags"},{"content":"","date":"2026年5月26日","externalUrl":null,"permalink":"/posts/","section":"Posts","summary":"","title":"Posts","type":"posts"},{"content":"","date":"2026年5月26日","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"2026年5月26日","externalUrl":null,"permalink":"/tags/xray/","section":"Tags","summary":"","title":"Xray","type":"tags"},{"content":"","date":"2026年5月26日","externalUrl":null,"permalink":"/tags/%E5%AE%89%E5%85%A8/","section":"Tags","summary":"","title":"安全","type":"tags"},{"content":"","date":"2026年5月26日","externalUrl":null,"permalink":"/tags/%E4%BB%A3%E7%90%86/","section":"Tags","summary":"","title":"代理","type":"tags"},{"content":"Xray_bash_onekey 越来越复杂了：Reality、ws、gRPC、xHTTP、Nginx、Fail2ban、流量阻断、GeoData 自动更新……菜单越来越长，但安全问题不会因为菜单好看就自己消失喔。\n有些坑不是脚本的 bug，是你装的时候没仔细看，服务器环境乱成一锅粥啦，或者把后端端口直接晒给全世界。这篇把几个最容易翻车的地方重新捋一遍——丑话说在前头我才能安心嘛。\nSSH 入口 # 脚本需要 SSH 到服务器。很多 VPS 默认开 22 端口，密码一弱就是「欢迎来试」的状态。\n几个最基本的：\n密码搞强点，最好改成密钥登录。 不用 root 密码登录就关掉。 装 Fail2ban：idleleo --set-fail2ban。 云厂商安全组里只开必要端口，别的全关上。 Fail2ban 不是无敌的，但它能挡掉一大批低成本爆破。日志安静了，人也舒服了——至少不用半夜被报警吵醒嘛。\nReality Target 不要乱填 # Reality 的 Target 域名非常关键。特别是别随手填一个套了 Cloudflare 或别的 CDN 的域名，不然鉴权失败的流量直接被转发到目标站，你的服务器就成了免费加速节点——谁路过都能用，账单你来付。\n这个问题详细说过了：Xray Reality 协议的风险。\n如果你就是要利用这个特性做自己的加速链路，也不是不行啦，但一定搭配 Nginx serverNames 分流。裸着让 Reality 乱跑？别，真的别。\nNginx 和 CDN # TLS 模式下，Nginx 是前置入口，适合 ws/gRPC/xHTTP 这类传输，也更适合配合 CDN。用 Cloudflare 的注意：先让脚本装好证书和配置，再开代理小云朵。\ngRPC 还要去 CF 的网络设置里打开 gRPC 支持。不然就是「我配好了为什么不通」→「哦你没开选项啊」的经典循环。\n另外说一句得罪人的话：CDN 不是加速万能药。它能藏源站，也可能拖慢速度。你是要「别人看不到我」还是要「跑得飞起」，心里先想清楚喔。\n后端端口别裸奔 # ws/gRPC/xHTTP ONLY 模式没有 TLS，天生就是当后端用的。直接暴露给公网当主节点？想什么呢。\n如果搭了后端负载均衡：\n后端端口只允许主服务器访问。 能用内网 IP 就内网。 前后端 UUID、path、serviceName 统一。 权重别乱调——小机器就别扛大流量了嘛。 后端没有完整防护的时候，暴露出去就是在邀请别人来串门。而且是那种不打招呼还狂吃你家零食的串门。\n证书与邮箱 # TLS 模式要证书。脚本支持自动 Let\u0026rsquo;s Encrypt 签发，也支持你自己放证书到 /etc/idleleo/cert（文件名 xray.crt 和 xray.key）。\n证书不是「申请一次管一辈子」的东西。域名解析、80/443 端口、CDN 代理状态、续签任务——哪个环节出问题证书都可能挂。看到证书报错，先检查域名还在不在、CF 是不是提前开了代理。\n流量阻断 # 脚本里现在有 Xray 流量阻断：\nidleleo --traffic-blocker 可以按国家/地区拦 IP 和域名，也能拦 BT、广告、私有网络访问。详细说看：Xray进阶玩法 - 封锁指定国家/地区的 IP 和域名。\n这类规则最适合处理「不希望它走代理」的流量。它不是防火墙平替，但作为代理出口的一道闸，很实用。\n最后 # 脚本能帮你把复杂流程理清楚，让你少踩一半坑。但服务器终究是你的——域名、端口、证书、客户端支持、日志异常，自己心里要有数。\n懒可以。完全不看提示一路回车……不太行。一键脚本已经对这个世界很努力了，但这个世界对一键脚本用户又没那么温柔。还是多看两眼吧，乖～\n","date":"2026年5月26日","externalUrl":null,"permalink":"/posts/jbdjxray/","section":"Posts","summary":"","title":"脚本搭建 Xray 的部分安全问题","type":"posts"},{"content":"","date":"2026年5月26日","externalUrl":null,"permalink":"/categories/%E7%BD%91%E7%BB%9C%E6%8A%80%E6%9C%AF/","section":"Categories","summary":"","title":"网络技术","type":"categories"},{"content":"","date":"2026年5月26日","externalUrl":null,"permalink":"/","section":"云云舒","summary":"","title":"云云舒","type":"page"},{"content":"","date":"2026年5月26日","externalUrl":null,"permalink":"/tags/reality/","section":"Tags","summary":"","title":"Reality","type":"tags"},{"content":"这篇本来是草稿，仓库地址、安装命令、模式名称全停在 2021 年。现在按当前 Xray_bash_onekey 重新整理一版。\n如果你只是想快速搭一个能用的 Xray，全程回车就行，默认值够用了。别一上来就每个选项都自己改——翻车的多半不是脚本难，是手太痒。\n准备工作 # 你需要：\n一台境外 VPS，具备公网 IP。 服务器系统建议使用 Debian 12+ 或 Ubuntu 24.04+。 如果安装 TLS 模式，需要准备一个解析到服务器 IP 的域名。 如果安装 Reality 模式，需要准备符合 Xray 要求的 Target 域名。 服务器里要有 curl。 安装 curl：\napt install -y curl CentOS Stream 用户可以用：\nyum install -y curl 新手不建议使用太旧的系统模板，也不建议在装了一堆面板和环境的机器上硬装。纯净环境少很多麻烦。\n安装命令 # 当前安装命令是：\nbash \u0026lt;(curl -fsSL https://raw.githubusercontent.com/hello-yunshu/Xray_bash_onekey/main/install.sh) 安装完成后，可以直接输入：\nidleleo 进入管理菜单。\n安装模式怎么选 # 当前主要模式：\nReality + Nginx：推荐模式，可按需附加 ws/gRPC/xHTTP 简单协议用于负载均衡。 Nginx + TLS：支持 ws、gRPC、xHTTP，适合域名和证书都准备好的场景。 ws/gRPC/xHTTP ONLY：无 TLS 的独立入站，主要用于后端服务器或负载均衡。 XTLS ONLY：仅用于特定中转或自定义场景。 Docker：镜像内预装 Xray、Nginx 与主脚本。 如果你不知道怎么选，优先 Reality + Nginx 或 Nginx + TLS。ONLY 模式不要直接暴露给公网当主节点用，它更像后端工具。\nws、gRPC、xHTTP 怎么选 # 安装 ws/gRPC/xHTTP 相关模式时，会看到：\n1: ws 2: gRPC 3: xHTTP 4: ws+gRPC+xHTTP 简单建议：\n想稳妥，先选 ws。 想走 HTTP/2 风格传输，可以试 gRPC。 想测试新传输，可以试 xHTTP，但注意 Clash 目前不支持 xHTTP。 想一个服务器多准备几条路，可以选 ws+gRPC+xHTTP。 路径也要注意：ws 和 xHTTP 的 path 客户端里要带 /，gRPC 的 serviceName 不要带 /。\n常用命令 # idleleo --show # 查看安装信息 idleleo --update # 更新脚本 idleleo --xray-update # 更新 Xray idleleo --nginx-update # 更新 Nginx idleleo --set-fail2ban # 设置 Fail2ban idleleo --traffic-blocker # 设置 Xray 流量阻断 idleleo --port-traffic # 查看端口实时流量 如果不知道命令，运行：\nidleleo --help 安全建议 # 安装完不是结束，至少做几件事：\nSSH 不要用弱密码，能用密钥就用密钥。 建议安装 Fail2ban。 Reality 模式建议搭配 Nginx 前置。 有滥用风险时开启流量阻断。 Cloudflare 用户请先确认脚本安装成功，再开启 CDN 代理。 定期更新脚本、Xray、Nginx、证书和 GeoData。 脚本能帮你省不少事，但它不是管家。该懂的网络常识还是要懂一点，别指望脚本替你思考。\n延伸阅读 # Reality 安装：搭建 Xray Reality 协议服务器\nReality 风险：Xray Reality 协议的风险\ngRPC 协议：Xray进阶玩法 - 使用 gRPC 协议\nxHTTP 协议：Xray进阶玩法 - 使用 xHTTP 协议\n后端负载均衡：XRay进阶玩法 - 搭建后端服务器负载均衡\n","date":"2026年5月26日","externalUrl":null,"permalink":"/posts/2023-da-jian-xray-fu-wu-qi-zui-xin-jiao-cheng/","section":"Posts","summary":"","title":"搭建 Xray 服务器最新教程","type":"posts"},{"content":"","date":"2026年5月26日","externalUrl":null,"permalink":"/tags/%E6%9C%8D%E5%8A%A1%E5%99%A8%E6%90%AD%E5%BB%BA/","section":"Tags","summary":"","title":"服务器搭建","type":"tags"},{"content":"","date":"2026年5月26日","externalUrl":null,"permalink":"/tags/nginx/","section":"Tags","summary":"","title":"Nginx","type":"tags"},{"content":"后端负载均衡这个功能在脚本里活了很久了，但 Xray_bash_onekey 已经不是当年那个只会说「ws ONLY」的小可爱了。ws、gRPC、xHTTP —— 三种协议现在都能进 Nginx upstream 管理，旧教程里那套说法早就该扔进垃圾桶啦。\n先泼一盆水让你冷静一下：负载均衡不是叠加带宽，也不是一个下载任务变多线下载。 它更像一个聪明的前台小姐姐，有客人来了就看看后面哪台机器比较闲，把你领过去。多人同时用的时候效果明显，一个人用？那就省省吧～一台就够了。\n现在支持哪些协议 # 当前脚本的 Nginx upstream 管理四分类：\nws → .wsServers gRPC → .grpcServers xHTTP → .xhttpServers Reality 负载均衡 → .realityServers 这篇说的是普通后端的玩法——ws/gRPC/xHTTP 被 Nginx 转发到后端服务器那种。Reality 负载均衡是另一个话题，想看那边去：如何部署 Reality协议 服务端负载均衡。\n准备工作 # 最少两台 VPS，再多也不嫌多嘛（只要钱包不哭）：\n主 VPS：负责接客、TLS/Nginx、upstream 转发。这是门面，别拿 1 核小鸡糊弄。 后端 VPS：只跑 ws/gRPC/xHTTP ONLY 或者 Reality 附加的简单协议，低调地在后面扛活。 强烈建议同一区域、同一内网。 跨地区的后端看起来很帅是吧？实际你会发现：客户端连过来，每个后端响应时间都不一样，快的等慢的，体验反而不如一台高性能单机。\n如果云厂商给了内网，用内网 IP 通信。后端端口不要暴露给全世界——那是给自己找麻烦喔。\n主服务器怎么搭 # 在主服务器上运行脚本：\nbash \u0026lt;(curl -fsSL https://raw.githubusercontent.com/hello-yunshu/Xray_bash_onekey/main/install.sh) TLS 前置的话选：\n安装 Xray (Nginx+ws/gRPC/xHTTP+TLS) 传输协议选 ws、gRPC、xHTTP 或者 ws+gRPC+xHTTP 全都要。装完记得记下这些——别跳过，后面后端要一模一样：\nUUID 或 UUID 映射字符串 ws path / gRPC serviceName / xHTTP path 对应协议的端口 域名和证书状态 主服务器一个 path，后端另一个 path，然后怪 Nginx 不干活——这种事我见太多了，别当主角嘛。\n后端服务器怎么搭 # 后端选这个：\n安装 Xray (ws/gRPC/xHTTP ONLY) 这个模式给你的是纯协议入站，没有 TLS，就是给主服务器当后端小兵用的。安装时协议要和主服务器一致：UUID 一样、path/serviceName 一样。端口建议用高位的，比如 10000+，然后防火墙只放行主服务器的内网 IP。\n如果你用 gRPC，后端 serviceName 和主服务器一致；xHTTP 的话 path 带 /；ws 也一样。\n添加到主服务器 # 回到主服务器：\nidleleo --add-upstream 脚本会问你要管哪个协议的负载均衡——ws、gRPC 还是 xHTTP。\n创建后端文件时填：\nhost：后端 IP，优先内网。 port：后端协议端口。 weight：权重，越大被翻牌概率越高。 主服务器自己默认权重 50。后端机器性能好的调大点，线路一般的调小点。1 核小鸡权重拉满，然后问「为什么忽快忽慢」——你说呢？\n什么时候适合用 # 适合的场景：\n多用户同时在用，一台机器的带宽或 CPU 扛不住。 同一区域有好几台闲置 VPS。 想隐藏后端 IP，只暴露主服务器给客户端。 不太适合：\n就你一个人用。 后端分布在不同国家地区，延迟参差不齐。 你指望单连接带宽直接翻倍——别想啦，不是合体。 负载均衡是分摊请求，不是叠加强化。 这句话值得你再读一遍。理解错了后面一定会踩坑，而且踩了还来找我哭。\n最后絮叨 # 后端服务器一定配合防火墙，只让主服务器访问后端端口。主服务器可以装 Fail2ban、开流量阻断、设 GeoData 自动更新。\n现在脚本入口很统一，idleleo 一个命令进去啥都有。功能多了以后最重要的不是每个都开，是知道自己开了什么。乱开一堆然后忘了，三个月后排查问题，那场面，光是想想就刺激呢～\n","date":"2026年5月26日","externalUrl":null,"permalink":"/posts/xrayjin-jie-wan-fa---da-jian-hou-duan-fu-wu-qi-fu-zai-jun-heng/","section":"Posts","summary":"","title":"XRay进阶玩法 - 搭建后端服务器负载均衡","type":"posts"},{"content":"","date":"2026年5月26日","externalUrl":null,"permalink":"/tags/%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1/","section":"Tags","summary":"","title":"负载均衡","type":"tags"},{"content":"","date":"2026年5月26日","externalUrl":null,"permalink":"/tags/cdn/","section":"Tags","summary":"","title":"CDN","type":"tags"},{"content":"","date":"2026年5月26日","externalUrl":null,"permalink":"/tags/grpc/","section":"Tags","summary":"","title":"GRPC","type":"tags"},{"content":"gRPC 刚进 Xray 那会儿确实像个「新玩具」，人人都想上去摸两把。现在回头一看，它已经是 Xray_bash_onekey 里的老面孔了嘛——单独选也行，和 ws、xHTTP 一起开也行，低调地住在菜单第 2 号位。\n所以这篇不搞 2021 年那种「快来尝鲜」的口吻了。现在该问的是：在当前脚本里，gRPC 怎么选，跟 ws/xHTTP 到底啥区别，以及——哪些地方最容易手滑填错。\ngRPC 是什么 # 基于 HTTP/2，多路复用、头部压缩、双向流——这些都是 HTTP/2 系的能力。放到 Xray 里，可以先粗暴理解为「另一种走 HTTP/2 风格的传输方式」。不玄乎。\n它不一定比 ws 快，也不一定比 xHTTP 好。快不快最终看你那条线路给不给面子——客户端、CDN、运营商、服务器位置，哪个不是变量呢？别把协议当玄学神器，能稳定跑的才是好协议。\n怎么装 # 现在脚本入口统一，装就完事：\nbash \u0026lt;(curl -fsSL https://raw.githubusercontent.com/hello-yunshu/Xray_bash_onekey/main/install.sh) 装 TLS、Reality 附加协议、或者 ws/gRPC/xHTTP ONLY 后端的时候，都会看到这个选择：\n1: ws 2: gRPC 3: xHTTP 4: ws+gRPC+xHTTP 单走 gRPC 就 2。想给客户端多备几条路就 4——脚本会同时生成 ws、gRPC、xHTTP 的端口、路径、分享链接和二维码，一次给你配齐。\nserviceName 别画蛇添足 # gRPC 最容易翻车的地方：serviceName。\nws 和 xHTTP 像正常 URL 路径，要带 /。但 gRPC 的 serviceName 不要 /！脚本输出是 grpcdemo，客户端就填 grpcdemo。你自作主张加个 /grpcdemo？恭喜，连不上。\n这个小细节，错了就真的不通。每次有人说「我配置完全一样就是不通」，我心里都先默念：你是不是多打了一个 /？\n负载均衡 # 现在 Nginx 负载均衡支持 ws、gRPC、xHTTP 三种协议。在主服务器上：\nidleleo --add-upstream 然后选 gRPC。它对应的后端文件是 .grpcServers，后端服务器需要相同 UUID、相同 serviceName、开放对应的 gRPC 端口。详细看：XRay进阶玩法 - 搭建后端服务器负载均衡。\nCDN 别忘开开关 # gRPC 能套 Cloudflare——但你去 CF 控制面板把 gRPC 打开了吗？没开的话，服务端怎么配都是白搭，CDN 那边一句「不认识」就给你拦了。\n另外，CDN 不是万能加速器。想藏源站就开，想极限速度就直连。性能、安全、稳定，三样全都要？醒醒，不存在那种好事。\ngRPC vs xHTTP 怎么选 # 现在脚本有 xHTTP 了，gRPC 不是你唯一的选择。\n简单粗暴的建议：\n客户端支持 gRPC + 你要走 CDN → 试 gRPC。 想要最大兼容性 → ws 永远是最稳的。 想尝鲜 → xHTTP，但 Clash 目前不支持，注意避坑。 做负载均衡 → 主服务器和后端协议必须一致，别 gRPC 对 xHTTP 乱搭。 最后一句真心话：协议好不好，跑一下就知道。 选项全在同一个菜单里摆着呢，实测十分钟比你脑子里纠结一晚上靠谱一百倍。\n","date":"2026年5月26日","externalUrl":null,"permalink":"/posts/xrayjin-jie-wan-fa---shi-yong-grpcxie-yi/","section":"Posts","summary":"","title":"Xray进阶玩法 - 使用 gRPC 协议","type":"posts"},{"content":"","date":"2026年5月26日","externalUrl":null,"permalink":"/tags/ai/","section":"Tags","summary":"","title":"AI","type":"tags"},{"content":"一键脚本已经够懒了对吧？但人类的本质就是——还能更懒。于是就有了这个新玩具：AI Skill 自动部署。对，你没看错，把部署 Xray 这件事丢给 AI，然后端着咖啡等链接就行。\n传统方式你懂的：SSH 登录，敲命令跑脚本，然后开始回答一堆灵魂拷问。域名？Reality 还是 TLS？端口改不改？UUID 自定义吗？Nginx 装不装？老用户觉得家常便饭，第一次见的人看到第三行就已经想砸键盘了。\nAI Skill 就是把这些「在终端里当场回答的问题」提前收了。你只要用大白话说你要什么，AI 帮你把信息凑齐，生成非交互式脚本，哐哐哐跑完，VLESS 链接双手奉上。懒人从今天起也可以是看起来专业的人了～\n省了什么 # Xray_bash_onekey 本身已经把安装简化到「回车就完事」了。但交互式脚本有个绕不开的问题：你得知道每步在问什么。\nReality 要目标域名，TLS 要解析好的域名，ws/gRPC/xHTTP 各有端口和路径。老用户觉得这有啥，新人会觉得自己在参加网络工程考试——而且还没复习。\nAI Skill 又砍了一刀：你要在终端当场回答的那些问题，提前用对话搞定。它就像一个盯着你问清楚才肯动手的小助手，不是让你对着脚本猜谜语。\n怎么用 # 项目里有一个单独的 Xray_bash_onekey_skill。在支持 Skill 的 AI 工具里，直接说：\n帮我在服务器上搭建 Xray 之后 AI 会像查户口一样确认信息：服务器地址、登录方式、安装模式、域名准备……全问清楚了才动手。脚本跑完，连接信息直接给到你，不墨迹。\nSkill 底层还是 idleleo 那套命令体系，常见安装模式和维护入口都在：\n目前覆盖的模式是 Reality、TLS、ws ONLY、XTLS ONLY——先把最常见最容易标准化的搞定。那种特别骚的操作和特别个性的玩法，还是建议你自己看一眼配置。AI 可以帮你走流程，但不能替你背锅。\n和一键脚本的关系 # AI Skill 不是又造了个新安装器。它本质上是 Xray_bash_onekey 上面套了一层自动对话。真正干活的是原来的脚本——装 Xray、配 Nginx、签证书、输出配置，全是老一套，只是你不需要亲手选了。\n这点很重要。它不是「AI 现场手搓配置文件」，也不是「从网上随便 copy 一段命令」。交互式脚本的选择过程被变成了可控的非交互式流程。底层还是熟悉的那些目录、服务、证书和配置。\n所以部署完你想自己管理，照样 idleleo 登录进去。更新、查看配置、开流量阻断——AI 送你进门，后面怎么布置，你说了算。\n别当魔法 # 说句扫兴但必要的：AI Skill 降低的是操作门槛，不是智商门槛。\n域名解析好了没、系统支不支持、端口有没有被占、客户端认不认这个协议——这些问题不会因为你说了「AI 帮我」就自动消失。它能让你少犯错，但如果你基础条件就是错的，它也只能更快地把错误跑出来给你看。\n还有，涉及 SSH 和服务器操作，只在你信得过的环境里用。工具越自动，越该知道它在干嘛。懒可以，糊涂不行。\n谁适合 # 我觉得主要两种人。\n第一种：新手。想搭个能用的 Xray，但不想第一次就被术语劝退。Skill 把问题拆得像聊天，至少不会让你盯着终端那行提示发呆到怀疑自己智商。\n第二种：老用户。别笑，老用户才最懂懒的价值。每个选项啥意思门儿清，就是不想每台新服务器重复一遍机械操作。让 AI 把固定流程跑完，自己看一眼结果就行——这不香？\n所以不是「AI 取代一键脚本」，就是「一键脚本又少按了几次键」。能自动的自动，不能自动的也别折磨人——这个精神，很符合。\n","date":"2026年5月26日","externalUrl":null,"permalink":"/posts/xray-ai-skill-deployment/","section":"Posts","summary":"","title":"用 AI Skill 自动部署 Xray：懒人终于赢了一次","type":"posts"},{"content":"","date":"2026年5月26日","externalUrl":null,"permalink":"/tags/%E8%87%AA%E5%8A%A8%E9%83%A8%E7%BD%B2/","section":"Tags","summary":"","title":"自动部署","type":"tags"},{"content":"","date":"2026年5月26日","externalUrl":null,"permalink":"/tags/geoip/","section":"Tags","summary":"","title":"GeoIP","type":"tags"},{"content":"","date":"2026年5月26日","externalUrl":null,"permalink":"/tags/geosite/","section":"Tags","summary":"","title":"GeoSite","type":"tags"},{"content":"之前写 Reality 风险的时候唠叨过：配置不对，你的服务器会被别人拿去薅流量。那时候的套路是 Nginx 挡前面、SNI 分流、Fail2ban 封 IP——能用，但总有种「发现一个坏蛋打一个」的老实人气场，一点都不酷。\n现在 Xray_bash_onekey 终于加了一个更狠的功能：流量阻断。直接按国家/地区拦 IP 和域名，顺手还能掐掉 BT、广告域名、私有网络访问。简单说：我家的代理，我说了算，不想让谁过谁就别想过～\n能拦什么 # 脚本里目前有四把小剪刀，可以分别咔嚓掉：\n指定国家/地区：基于 geoip:xx 和 geosite:xx，IP 和域名都拦。 BT 下载：基于 protocol: bittorrent，种子流量直接掐。 广告域名：基于 geosite:category-ads-all，清爽到底。 私有网络：基于 geoip:private，别来碰我的内网。 重点说国家/地区阻断。比如你填个 cn，脚本会同时生成域名规则和 IP 规则，也就是 geosite:cn 和 geoip:cn 都会生效。双重拦截，不怕漏网之鱼～\n不是什么高深操作，想法超级朴素：我的代理，有些方向的流量，就是不想让你从这走。尤其是后端多、跳板多、Reality 附加协议多的机器，多一道规则真的比事后对着流量账单发呆强。\n怎么开 # 登录服务器，一句话：\nidleleo --traffic-blocker 或者 idleleo 进主菜单，选「设置 Xray 流量阻断」。进去是长这样：\n几个入口清清楚楚：看规则状态、管理阻断规则、更新 GeoData、重置全部规则。第一次用的话，先更新 GeoData，让 geoip.dat 和 geosite.dat 是最新版。脚本自己也会检查，缺了就自动下载，不用你到处找文件——这还算贴心吧？\n添加国家/地区的时候，填两位代码就行：\ncn,jp,ru 国家/地区阻断是一个独立的人口，可以添加，也可以按编号删掉：\n脚本会自动去重，不合法代码也会跳过。加完以后立刻应用规则并重启 Xray。看到「重启」别紧张，这是让新路由生效的正确姿势，不是脚本在翻车。\nGeoData 自动更新 # 这种功能最怕的不是你第一次没配好，而是半年后规则文件老得像出土文物，拦什么东西早就不准了。所以脚本里塞了 GeoData 更新菜单，可以单独更新 geoip.dat、geosite.dat，也可以设自动更新。\n自动更新默认每周一凌晨 3 点偷跑一次。这个时间点我很满意：你在睡觉，服务器悄悄更新，醒来一看啥都弄好了，多优雅。规则文件新一点，国家/地区匹配才不会闹笑话。\n如果你的服务器环境比较特别，建议第一次设完以后看一眼 crontab 写没写进去。脚本菜单里也会显示当前 GeoData 的状态——版本、更新时间、有没有新版，一清二楚。\n别怼自己脸上 # 说点认真的。流量阻断不是那种「点一下广告消失」的轻量级功能。它会直接改 Xray 的 routing 配置，应用的时候会重建路由规则。如果你自己手写了复杂路由，启之前一定要备份配置。\n脚本会帮你做备份，重启失败了也会尝试恢复，但服务器终归是你的，心里要有点数。特别是已经搞了自定义分流、复杂 outbound、特殊 DNS 策略的玩家，别闭眼乱点。\n还有一个小细节：启用国家/地区或私有网络阻断时，脚本会使用 IPIfNonMatch 这类策略——域名规则匹配不到再用 IP 判断，算是双重保险。启用 BT、国家/地区、广告规则时，还会打开协议嗅探。听起来玄乎，其实就是让 Xray 有足够多信息去判断：这条流量要不要掐？\n谁适合开 # 如果你一个人用，流量不大也没被薅过，这功能不是非开不可。工具不是护身符，开得多就安全大那是不存在的。\n但你如果属于下面这些人，就很值得试试：\n服务器流量异常，找不到原因，看着账单懵。 后端节点多，负载均衡、Reality 附加协议一大堆。 不想让代理替你跑 BT、广告、私网访问这些杂活。 某些方向的流量，从一开始就不是你要服务的人。 最后总结一句人话：Fail2ban 像门卫保安——谁打我我封谁；流量阻断像门禁系统——这类人，根本别进来。两个不冲突，一起打开，服务器会清静到让你感动。\n","date":"2026年5月26日","externalUrl":null,"permalink":"/posts/xray-traffic-blocker-country-ip/","section":"Posts","summary":"","title":"Xray进阶玩法 - 封锁指定国家/地区的 IP 和域名","type":"posts"},{"content":"","date":"2026年5月26日","externalUrl":null,"permalink":"/tags/%E6%B5%81%E9%87%8F%E9%98%BB%E6%96%AD/","section":"Tags","summary":"","title":"流量阻断","type":"tags"},{"content":"","date":"2026年5月26日","externalUrl":null,"permalink":"/tags/vless/","section":"Tags","summary":"","title":"VLESS","type":"tags"},{"content":"","date":"2026年5月26日","externalUrl":null,"permalink":"/tags/xhttp/","section":"Tags","summary":"","title":"XHTTP","type":"tags"},{"content":"Xray_bash_onekey 最近加入了 xHTTP 协议。是的，继 ws、gRPC 之后，又多了一个可以选的传输方式。协议越来越多，选择困难症也越来越严重——恭喜大家，快乐又增加了。😏\n不过话先说清楚，xHTTP 不是来掀桌子的，不是要把 ws 和 gRPC 踹出门外。它更像是给不同的网络环境多留一条路：能用就试试，合适就留着，不合适就退回去。代理这事儿吧，有时候道理没用，最终还是你那条线路说了算。\nxHTTP 是什么 # 不扯名词了。xHTTP 就是 Xray 里一个新的 HTTP 系传输方式，和 ws、gRPC 一样，属于 VLESS 外面再包的一层。用途就是适配不同网络、不同前置、不同客户端。\n在脚本里，xHTTP 已经被妥妥收进了原来的 ws/gRPC 选择流程。装 TLS 可以选、装 Reality 附加协议可以选、甚至单独装个 xHTTP ONLY 当后端也可以。\n更懒的话，直接选 ws+gRPC+xHTTP 同时启用。脚本会分别生成对应端口、路径、分享链接和二维码。好处是一个服务器上多放几条路，客户端支持哪个用哪个；坏处嘛——配置看起来会很热闹，别把自己看晕就行。\n如何安装 # 用脚本 Xray_bash_onekey 正常装就行。\n主菜单里 xHTTP 已经是正经选项了，不是什么藏在角落里的实验品：\n全新安装，选传输协议时能看到：\n1: ws 2: gRPC 3: xHTTP 4: ws+gRPC+xHTTP 实际界面大概长这样：\n试试水就选 3，想多留几条路就选 4。脚本会接着问你 xHTTP 的端口和伪装路径——不知道怎么填就回车，默认值通常比你的临场发挥靠谱。\n装完后脚本输出 xHTTP 的 VLESS 分享链接和二维码。注意：xHTTP 的 path 在客户端要带 /，脚本输出也会提醒。别学 gRPC 那个 serviceName——两个不是一种东西，搞混了就连不上，连不上就会来找我。\n客户端支持 # 这里必须泼一盆冷水：不是所有客户端都认 xHTTP。\n脚本已经做了提示——Clash 目前不支持，所以 Clash 配置里会跳过 xHTTP。ws/gRPC 有 Clash 配置，xHTTP 没有，不是脚本偷懒，是客户端那边还没接上。\n如果你用的客户端支持 xHTTP，直接导入分享链接；如果导进去发现识别不了，先别怀疑人生，看看客户端版本和内核是不是真支持。\n什么时候适合用 # 如果你现在 ws 舒服、gRPC 延迟也不错，那 xHTTP 未必能带来什么天翻地覆的变化。它更适合：\n同一台服务器想多准备一种传输方式，方便切换。 ws 或 gRPC 在某些网络下表现拉胯，想换条路试试。 做后端负载均衡时，希望后端协议选择更灵活。 单纯手痒——看到新协议不试一下浑身难受。 最后一个理由也是理由，折腾本来就是这种工具的核心乐趣，不丢人。\n一点提醒 # xHTTP 已经被脚本接入到安装、配置修改、用户管理、分享链接、状态输出里了。但「服务端显示安装成功」不等于「客户端能用」。一定要真的连一下，看看能不能稳定访问。\n另外，如果你选了 ws+gRPC+xHTTP 同时启用，建议把每个协议的端口、路径、客户端支持情况记清楚。配置多不是问题——问题是三天后忘了自己当初填了什么，然后对着服务器进入沉默冥想状态。\n总之，xHTTP 让 Xray_bash_onekey 的玩法又丰富了一点。它不是「必须换」的协议，是「值得试」的协议。至于在你这好不好用——挂上去跑两天，答案就有了。\n","date":"2026年5月26日","externalUrl":null,"permalink":"/posts/xray-xhttp-mode/","section":"Posts","summary":"","title":"Xray进阶玩法 - 使用 xHTTP 协议","type":"posts"},{"content":"在搭建 Xray Reality 协议服务器里特别提过：Target 域名别用套 Cloudflare 的。为什么？这篇把坑挖开给你看。\nReality 的风险 # 如果 Target 域名指向了 Cloudflare CDN 这类特殊 IP 的网站，那么非法的 Reality 请求——也就是鉴权失败的那些流量——会直接转发给目标域名。后果就是：你的服务器成了 Cloudflare 的免费端口转发工具，别人扫描到以后就能薅你的流量。\n用人话说：Reality 这个特性让 Target 套 CDN 的服务器变成 CDN 的边缘 IP。谁路过都能用，账单你来付。免费给别人当加速节点，亏不亏？\nXray 开发者不是不知道这个。但他们说了，为了更好的伪装，这种情况没法避免。所以问题不在 Xray 有 bug，而是你不设防就是在开门迎客。\n实际遭遇 # 我没有配置任何防护，Target 随手填了个套 Cloudflare 的域名。猜猜几天后发生了什么？\n上面这个 IP，每秒几百次请求。下面这张图里是我封掉的 IP 总数——几百个，就短短几天。几百个人在薅我服务器的羊毛！！！＼(º□ºl|l)/\n所以千万千万别小看互联网捣蛋鬼的力量。设不对就是这种下场。\n怎么防 # 难道没救了吗？？NONONO～机智的我给 Reality 套了个 Nginx！用 Nginx 在前面做 SNI 分流，匹配的域名才放给 Xray，不匹配的直接掐。这样一来，不是自己人的域名根本过不去，薅羊毛的就只能干瞪眼啦~\n你可能会说：那直接不用套 Cloudflare 的域名不就行了。机智如你！但是——为什么不好好利用 Xray 这个特性呢？把 Reality 服务器变成你自己的加速节点，不香吗？想法看这篇：利用 Reality 协议\u0026quot;漏洞\u0026quot;加速服务器。\n具体操作 # 用 Xray_bash_onekey 安装：\nbash \u0026lt;(curl -fsSL https://raw.githubusercontent.com/hello-yunshu/Xray_bash_onekey/main/install.sh) 选：\n3. 安装 Xray (Reality+ws/gRPC/xHTTP+Nginx) 安装过程中会看到这个提示：\n回车就行。现在 Nginx 有预编译好的包，安装飞快，别担心～\n以后要调整 Nginx 允许通过的域名，在脚本里：\n12. 变更 Nginx serverNames 配置 或者：\nidleleo --add-servernames Fail2ban 保安上岗 # 装完后强烈建议再装 Fail2ban。有些 IP 会像苍蝇一样反复尝试连接你的服务器，在 Nginx 日志里刷一堆错误。Fail2ban 就是用来收拾这种人的。\n在菜单里：\n29. 设置 Fail2ban 防暴力破解 或者：\nidleleo --set-fail2ban 规则我都写好啦，自动部署，不用谢～\n过段时间就能看到被封掉的 IP 列表了。\n再加一道流量阻断 # 如果你已经遇到奇怪的流量，或者想更狠一点，脚本里还有流量阻断：\n31. 设置 Xray 流量阻断 或者：\nidleleo --traffic-blocker 能按国家/地区 IP、BT、广告域名、私有网络等规则做阻断。Fail2ban 像门口保安，流量阻断像里面的防盗门。门多不丢人，省流量才是正经事～\n","date":"2026年5月26日","externalUrl":null,"permalink":"/posts/reality-xie-yi-de-feng-xian/","section":"Posts","summary":"","title":"Xray Reality 协议的风险","type":"posts"},{"content":"最近脚本 Xray_bash_onekey 更新后，Reality 已经不是当年那个「咦这是什么好新鲜」的小玩具了。现在 Reality、ws、gRPC、xHTTP、Nginx 全塞在同一个安装流程里，选项多得眼花缭乱。这篇帮你理一理，别到时候参数填错了还以为是玄学——玄学不背这锅喔～\nReality 介绍 # Xray Reality 协议，说白了就是让代理流量看起来像正常访问别人的网站。关键信息整理一下：\n安全性：消除 TLS 指纹特征，证书链攻击无效，比常规 TLS 更像样。\n省事：可以指向别人的网站，不用自己买域名配 TLS。对中间人来说，全程都是真实 TLS。\n代理专用：目标网站最低得是国外的、支持 TLSv1.3 和 H2，域名不要搞跳转那种。\n小心机：禁止回国流量，转发 TCP/80 和 UDP/443。Reality 对外就是端口转发，目标 IP 冷门点更佳。\nCDN 不能乱套：Target 域名乱选会出事，下面会细说。\n性能：配上 XTLS Vision 流控，表现不错。\n如何搭建 # 运行脚本：\nbash \u0026lt;(curl -fsSL https://raw.githubusercontent.com/hello-yunshu/Xray_bash_onekey/main/install.sh) 选择第三个：\n3. 安装 Xray (Reality+ws/gRPC/xHTTP+Nginx) 接下来一步一步走就行，该填的填，不想改的直接回车。真的很简单～\n装完之后如果忘了自己填了啥：\nidleleo --show 不要问我为什么要记参数。你当然可以不记，但以后排查问题的时候，你会对着屏幕沉默，而屏幕也会沉默地看着你。那种沉默，比尴尬还尴尬。\n重要参数 # Target 域名 # Target 域名就是 Reality 用来伪装的目标——流量看起来像在访问这个域名。通常是国外的、支持 TLSv1.3/H2 的大站，比如 Apple、Microsoft、Google 那些。\n推荐几个，拿去用：\nApple 系\nswdist.apple.com swcdn.apple.com updates.cdn-apple.com mensura.cdn-apple.com osxapps.itunes.apple.com aod.itunes.apple.com Microsoft 系\nwww.microsoft.com cdn-dynmedia-1.microsoft.com update.microsoft software.download.prss.microsoft.com Amazon 系\ns0.awsstatic.com d1.awsstatic.com images-na.ssl-images-amazon.com m.media-amazon.com player.live-video.net Google 系\ndl.google.com 其他\ngateway.icloud.com itunes.apple.com download-installer.cdn.mozilla.net airbnb（不同区域域名不同，自己搜） addons.mozilla.org www.lovelive-anime.jp 当然，最好用你自己的 Target 域名。没有的话用上面的也行。还可以用 RealiTLScanner 扫一下服务器附近 IP 段有什么好域名——这个工具是个小天使。\n务必注意 # Target 域名不要用套了 Cloudflare 的。 原因看这篇：Xray Reality 协议的风险。\n不是吓唬你。设错了，你的服务器会被别人拿去薅流量——羊毛长在你账单上，那画风可不美。\nserverNames # serverNames 就是 TLS 握手时告诉服务器「我要连哪个域名」的参数。\n大多数情况跟 Target 域名保持一致就行。乱填就等着连不上吧～\n以后要改的话：\n12. 变更 Nginx serverNames 配置 或者：\nidleleo --add-servernames 写在最后 # Reality 很强，但不是「开了就无敌」那种强。第一次搭建议全用默认值，等确认能稳定跑了，再去折腾 Nginx 分流、负载均衡、流量阻断这些进阶操作。\n先走通，再跑快。别还没学会走路就想着飞～\n","date":"2026年5月26日","externalUrl":null,"permalink":"/posts/da-jian-xray-reality-xie-yi-fu-wu-qi/","section":"Posts","summary":"","title":"搭建 Xray Reality 协议服务器","type":"posts"},{"content":" 关于云云舒 # 欢迎来到云云舒，这是 yunshu 的个人博客。\n这里记录着技术探索与生活感悟，主要关注服务器运维、网络技术、编程开发等领域。\n联系方式 # GitHub: hello-yunshu ","date":"2026年5月26日","externalUrl":null,"permalink":"/about/","section":"云云舒","summary":"","title":"关于","type":"page"},{"content":"说是\u0026quot;漏洞\u0026quot;有点过了，其实就是协议的一个特性——只不过这个特性玩不好的话会出事。具体风险看这篇：Xray Reality 协议的风险。先回顾下这个特性吧，毕竟不是每次默写都能全对，对吧～\nReality 协议风险回顾 # 如果 Target 域名套了 CDN，你的服务器就变成这个 CDN 的边缘 IP。其他人可以用你的服务器访问 CDN——相当于免费给别人加速，而流量从你账单上走。这种好人，咱不当。\n为了解决这个问题，Xray Reality 协议的风险 里的方案是：给 Reality 前面套个 Nginx，用 SNI 分流。只有那些匹配了域名的请求才能通过 Nginx 到达 Xray，不匹配的直接挡掉。\n那么，问个问题测测你的智商：如果我设置 a 域名可以通过 Nginx，但 Xray 的 Target 却是套了 Cloudflare 的 b 域名，会发生什么？\n倒计时 3\u0026hellip;2\u0026hellip;1\u0026hellip;\n利用\u0026quot;漏洞\u0026quot;加速服务器 # 答案是：a 域名会被原封不动发给 Cloudflare 节点！ 如果你把 a 域名也套了 Cloudflare，那你的 Reality 服务器就完美充当了一个加速节点。是不是很妙😏\n于是就有了下图：\n美国的 Xray ws 服务器套了 Cloudflare，你访问香港的 Reality 服务器，利用 Reality 的转发特性，香港跳转到 Cloudflare 边缘，Cloudflare 再回源到美国的 ws 服务器——一条加速链路就形成了！\n是不是很好玩～这可不只能加速你自己的服务器，什么 CDN、什么域名都行，只要你脑洞够大（好吧我现在就只想到这一个……）\n如何设置 # 先用 Xray_bash_onekey 装好 Reality，注意安装时要同时装 Nginx（搭配 Nginx 是必须的，原因上面说了）。然后在脚本里：\n12. 变更 Nginx serverNames 配置 或者直接：\nidleleo --add-servernames 就这：\n创建新的 serverNames 文件：\n输入你要加速的域名就好啦～是不是超简单。\n怎么用 # 以前大家说优选 IP，但优选 IP 这东西吧，不是时时都好使。这不正好，用 Reality 的特性给自己的 ws/gRPC/xHTTP 服务器加个速。\n地址栏填 Reality 服务器 IP，Host 栏填你上面设置的加速域名：\n是不是没听懂？没关系，这个确实有点绕。但解释起来好麻烦的……所以我懒得解释啦！！！\n反正知道好用就行，对吧～\n还是要提醒一句 # 玩法有趣归有趣，别忘了这本质上是在利用 Reality 的回落/转发特性。玩可以，防护一定要上：Nginx serverNames 分流、Fail2ban、流量阻断，该配的全配上。不然一边加速，一边被别人薅——从\u0026quot;玩法\u0026quot;变\u0026quot;赔法\u0026quot;，那可太惨了。\n","date":"2026年5月26日","externalUrl":null,"permalink":"/posts/use-reality/","section":"Posts","summary":"","title":"利用 Reality 协议「漏洞」加速服务器","type":"posts"},{"content":"最近更新了一个比较厉害的功能，嘿嘿。\n就是！可以在服务端对 Xray 的 Reality 协议进行负载均衡，哼哼。\n服务器示意图如下：\n大概访问情况如上。客户端只连主服务器，主服务器再把流量分给后面的二级服务器。看起来像一个入口，背后其实是一群小弟在干活，听上去就很让人安心。\n如果你想看普通 ws/gRPC/xHTTP 的后端负载均衡，可以看这篇：XRay进阶玩法 - 搭建后端服务器负载均衡。\n一级服务器（主服务器）如何搭建 # 首先你要运行脚本：Xray_bash_onekey。\nbash \u0026lt;(curl -fsSL https://raw.githubusercontent.com/hello-yunshu/Xray_bash_onekey/main/install.sh) 然后，在主服务器上，正常运行：\n3. 安装 Xray (Reality+ws/gRPC/xHTTP+Nginx) 运行中，当脚本问你：\n要不要开「负载均衡」\u0026ndash;\u0026gt; 必须开！ 要不要开「Nginx」\u0026ndash;\u0026gt; 也必须开！（因为负载均衡就靠它诶） 脚本在运行时会提问，如下图：\n在按照流程搭建时，必须要记下几个重要的值：\nUUID 映射字符串（UUID） Target 域名、serverNames（如果你自定义了） privateKey shortIds 主服务器 Reality 端口 上面这些值非常重要，每个都要记下来，知道不？\n忘了也别慌，可以运行：\nidleleo --show 二级服务器（次服务器）如何搭建 # 同样是运行脚本：Xray_bash_onekey。\n然后，在次服务器上，还是正常安装：\n3. 安装 Xray (Reality+ws/gRPC/xHTTP+Nginx) 在脚本运行中：\n自定义端口 \u0026ndash;\u0026gt; 建议用高位端口，比如 2xxxx 自定义 UUID / Target / privateKey / shortIds \u0026ndash;\u0026gt; 必须和主服务器一模一样！ 如上图，请输入之前记下的参数，保持每个都与主服务器一致。\n当脚本问你：\n要不要开「负载均衡」\u0026ndash;\u0026gt; 可以开，主服务器接入时会用到这套 Reality 参数 要不要开「Nginx」\u0026ndash;\u0026gt; 建议不要开 如果只用作次服务器，Nginx 不开就行。次服务器躲在后面当小透明，别让它过度暴露。\n安装完后，记下次服务器的 IP（建议内网 IP） 和 端口号。\n一级服务器如何连接二级服务器 # 回到主服务器，在脚本里选择：\n11. 变更 Nginx 负载均衡配置 也可以直接运行：\nidleleo --add-upstream 然后会有如下提示：\n根据要求，创建一个新的 realityServers 文件。创建过程会提示你输入：\n主机 host \u0026ndash;\u0026gt; 次服务器的 IP（建议内网） 端口 \u0026ndash;\u0026gt; 次服务器的端口号 权重 \u0026ndash;\u0026gt; 默认就行，想偏心谁就调大点 输入完后，就自动连接上啦！！\n可以在次服务器运行：\nidleleo --port-traffic 能看到对应端口有流量，就说明没问题啦。\n客户端怎么使用（优势） # 客户端只需要使用主服务器生成的配置即可，次服务器的不要使用。\n其实，完全可以搭建多个服务器，在客户端实现负载均衡。但是呢，分开请求可能会受到较慢的服务器拖累。\n所以！\n过去想在客户端做多 IP 负载均衡，配置一大坨还容易踩雷。现在只需要连主服务器，就等于偷偷访问了后面一群小弟，又快又稳！\n而且呢，还能把次级 IP 藏起来，不怕被 ban，超安心。\n注意事项 # 强烈建议：\n主服务器 + 所有次服务器放在同一个区域、同一个内网，理由如下：关于脚本的负载均衡功能 - 云云舒\n主服务器选择延迟低 + 带宽高的喔，毕竟客户端连接次服务器全靠它。\n记得在 VPS 控制台放行次服务器的端口，但只对内网放行就行。\n次服务器没有 Nginx 挡子弹，千万别让它乱跑流量，只当负载均衡小透明！\n安装完后，脚本会有额外提示，如图：\n看到 +Balance 就意味着这是负载均衡的服务器，这样就不会搞错啦。\n一些杂项：\n建议都开启 Fail2ban。 建议都开启 TCP 加速。 如果要做流量控制，可以配合 idleleo --traffic-blocker。 总之，负载均衡是把请求分摊到后端，不是把所有服务器叠起来变成一台更快的机器。搞清楚这个，就不会对它产生奇奇怪怪的期待了。\n","date":"2026年5月26日","externalUrl":null,"permalink":"/posts/bushu-reality-balance/","section":"Posts","summary":"","title":"如何部署 Reality 协议服务端负载均衡","type":"posts"},{"content":"下面主要说的是我很久之前写的一脚本👇\nhttps://github.com/hello-yunshu/Xray_bash_onekey\n这个脚本负载均衡功能已经存在很久了，但好像一直没说过的样子，这次来说一下~\n能不能叠加带宽 # 这是不存在的，负载均衡适用于高并发的场景，每次请求都会自动随机到一个可用的服务器上，那么这个服务器的带宽就是这次请求的带宽。它并不像某些下载软件，同时可以有多个请求再合并。所以呢，很不建议把一些带宽小的服务器组入负载均衡。如果这样做，在客户端有可能会出现一会儿快一会慢的情况。\n不同地区服务器组合在一起可以吗 # 是不推荐的喔。并不是地区分布越广，访问越顺畅。这个脚本的负载均衡有个主服务器的，主服务器与次服务器通讯是有延迟的，如果服务器在不同地点，服务器与服务器之间的通讯延迟会很大，反映到使用上会变卡。所以呢，推荐在一个地区使用，而且最好主服务器和次服务器在一个内网。\n负载均衡的策略是什么 # 这个脚本用的是nginx做的负载均衡，实话说，性能一般般的，但毕竟简单嘛。负载均衡的策略就是随机把请求给不同的服务器。当然也有检测服务器是否可用，当不可用的时候会自动切换到不同的服务器上。\n什么样的场景需要 # 高并发。比如说奥，家里同时有几个人在看YouTube的高清视频，这时，请求就会分散给几个服务器，进而把服务器带宽用满。但这也是理想的情况，一般来说，家里的带宽上限也会有影响。所以呢，应该是家中带宽足够，服务器带宽有限才合适使用负载均衡。\n空闲服务器多，有钱任性。这。。。祝福。。。\n机场\n最后说下脚本 # 脚本呢其实也在维护，最近有想把xtls这个协议改改。我的话最近遇到点“跨”的事情，所以变笨了😭，但我会尽量维护的！！现在可以选择的协议还是很多的，新出的协议也很不错，有机会，有可能的话。。我。。也会加进去的！！最后如果需要联系的可以在推特上找我，那里我看的比较多啦~\n","date":"2024年5月9日","externalUrl":null,"permalink":"/posts/1715234393850/","section":"Posts","summary":"","title":"关于脚本的负载均衡功能","type":"posts"},{"content":"","date":"2024年5月9日","externalUrl":null,"permalink":"/tags/%E8%84%9A%E6%9C%AC/","section":"Tags","summary":"","title":"脚本","type":"tags"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"}]