惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

J
Java Code Geeks
GbyAI
GbyAI
Google DeepMind News
Google DeepMind News
Jina AI
Jina AI
B
Blog
aimingoo的专栏
aimingoo的专栏
酷 壳 – CoolShell
酷 壳 – CoolShell
T
The Blog of Author Tim Ferriss
Last Week in AI
Last Week in AI
月光博客
月光博客
H
Help Net Security
V
Visual Studio Blog
量子位
A
About on SuperTechFans
博客园 - Franky
人人都是产品经理
人人都是产品经理
N
Netflix TechBlog - Medium
云风的 BLOG
云风的 BLOG
雷峰网
雷峰网
Martin Fowler
Martin Fowler
Microsoft Security Blog
Microsoft Security Blog
博客园 - 叶小钗
P
Proofpoint News Feed
MongoDB | Blog
MongoDB | Blog

V2EX

我用 AI 写代码,但终端管理反而成了累赘——于是我做了 codux [调研] 各位在公司都用什么 ide 和 agent 写代码? 老运维 share 一个运维平台 看到有公司考核 token 指标,很好奇大家上个月的 AI 账单是多少 GLM-Coding 调用持续报错: z.ai 的 Lite 套餐几乎无法使用,官方 Pro/Max 是否稳定? 现在还有什么渠道可以稳定安全地使用 Claude 吗? 上海漕河泾内推,本组有 2 个 hc,一个后端,一个前端,预算都是 20k 左右,不打卡,氛围好 如果 V2EX 上有一组不永久保存聊天记录(比如只保存 7 天或者 24 小时)的聊天室,那么会开启哪些有用或者有趣的可能? gemini cli 貌似挂了,一直返回 403 第一次在自媒体上赚到钱 收集了最近在使用的低价 GPT, Gemini,邮箱等 AI 会员的小店合集 讨论个大实话:现在企业还在说 AI 编程提效 20%, 30%的,真的太落后,没用懂 AI。因为包括很多前沿公司,已经狂奔到提效 200%-500%的情况 [招聘][远程][币安] 前端/后端/QA/iOS/Android 至少 3 年以上经验 目前有大量 HC 欢迎投递 Chatgpt Pro 用量用不完的可以开这些设置 面试的时候好像遇到钓鱼了,给各位避个坑 cursor 年续费 22 号到期, 自动续费是否还是老的计次套餐呢 被两件破事毁掉的一下午,琐碎的内耗消磨人的精力 使用 Planet 存储 Codex 的会话或者重要信息 如果业务部门领导不要你开发功能,而是要求你教会它用 claude code 开发功能,你会怎么做? 分享一个 MacOS 接绿联 CM818 USB 转 DP 转接器使用感受 我的 HR 朋友 10 年老 Java ,非全大专,大家帮忙看看简历 开源了一个 AI 口语练习工具,音素级发音评分,完全免费可自部署 V2EX 上有哪些你觉得很有趣、印象深刻的妹纸? 字节为啥不出个国内版 Vercel? 有在大马的朋友吗? 问个运营商问题 你们在有领导的公司大群发过的最大胆的消息是什么 公司裁员,目前没有工作。想试试摆摊,做一个移动鲜啤打酒车 我的硬盘 Memblaze Pblaze 5 Linux 下不识别,给 Linux 内核提交了补丁, AI 说有望被合并 只有我一个人觉得 codex 不好用?
[经验分享] 理清思路,写出最适合自己的分流规则其实很简单
madsword · 2026-03-30 · via V2EX

很多人在配置代理时,总觉得分组策略是门玄学,习惯去各大论坛找一份现成的“完美配置”。现在很多人在用 smart 内核确实越来越智能,自带了很多强大的功能,但客观来说,这种内核很重,而且再聪明的智能内核,也很难做到完全了解每个人的具体网络环境和使用习惯。
​分流这东西其实并不复杂。授人以鱼不如授人以渔,今天就简单梳理一下分流的底层逻辑,分享一下怎么根据自己的实际痛点,写出一套真正“一劳永逸”的规则。
​一、 核心痛点拆解
​首先,大前提很明确:墙内默认直连( DIRECT )。
对于墙外的普通网站,我们的核心诉求无非两个:既要 IP 稳定不乱跳,又要低延迟。 理清了这点,节点分组的思路就出来了:所有节点直接按地区分(比如香港、日本、韩国、新加坡、美国、英国等),然后按需分配策略。
​二、 策略组怎么选?看你重“求稳”还是重“速度”
​1. 忌讳 IP 乱跳的用户
如果你对 IP 稳定性要求很高(比如容易被风控的网站),每个地区分组可以使用 load-balance (负载均衡),并配合以下两个参数:
​consistent-hashing:将相同“目标地址”的请求,分配给策略组内的同一个节点。
​sticky-sessions:将相同“来源地址+目标地址”的请求分配给同一个节点,并设置个 10 分钟缓存过期。
这样一来,就能有效避免访问同一个网站时 IP 反复切换的问题。
​2. 追求极致速度的用户
如果你无所谓 IP 乱跳,只要快就行,那直接设置成 url-test (自动测速选择)。
建议把测速间隔 interval 设为 300 秒。如果你的节点太多,怕测速太频繁导致连接数爆炸,记得加上 lazy: true (懒惰状态)。默认为 true 时,只要没选中当前策略组,它就不进行测试,非常节省资源。
​三、 默认 Proxy 组的兜底逻辑
​各地区分好了,默认的 Proxy 分组怎么设置?推荐用 fallback (可用性测试)。
按节点的物理延迟,把地区组从低到高排个序。比如:香港节点延迟 30ms 排第一,新加坡 60ms 排第二,美国 160ms 排第三。
​划重点: 排序的最后一个,一定要加一个 DIRECT 兜底!万一哪天节点失效了,那些墙外但其实能直连的“漏网之鱼”也不至于跟着彻底断网。
​其实,一般人折腾到这一步就已经完全够用了。在你的 rules: 底下,只需要保留这两条极简的兜底规则:
​- GEOIP,CN,DIRECT
​- MATCH,Proxy
就能舒舒服服地实现国内外最快速的自动分流,日常上网毫无压力。
​四、 进阶定制:AI 、流媒体与特殊 App
​如果有更高阶的需求,可以在基础架构上继续添加特定分组:
​AI 专属组: 比如某些 AI 服务不能用香港节点,那就新建个“AI 分组”,把不可用的地区剔除。剩下的节点依然用 fallback ,按延迟从低到高排序。
​流媒体分组: 奈飞不想看日区,只想看美区?同理,建个分组,把不能用的地区全剔除,剩下的按喜好或者按延迟排序。
​特殊应用专治: 比如 The Weather Channel 的 App ,一检测到非美国 IP 就直接闪退。这种完全不需要搞复杂的分组,直接在 rules: 下方单独写死一条规则,分配给美国组就行。
​:warning: 防翻车提示: 配置文件里的规则是自上而下匹配的,匹配到了就不再往下看。所以你自定义的 App 规则一定要写在最前面。而列表的最底下,永远是刚刚提到的那两个雷打不动的兜底规则( GEOIP 和 MATCH )。
​五、 测速专属分组 (Speedtest)
​最后单独说下测速。你可以把所有国内外测速网站的规则集,全指定到一个名为 Speedtest 的特殊分组里。
这个组不需要 url-test ,也不要 fallback ,直接用 select (手动选择)。
选项列表里依次放入:第一条 DIRECT ,然后 Proxy ,接着是各个地区分组,或者你想单独测速的特定节点名称。平时不用管,想测谁的速度就手动选谁,干脆利落。
​按照这套逻辑去设置,只要你的节点没有全部失效,平时基本是不需要去手动切节点的,真正做到一劳永逸。