Skip to content

Comments

Proxy: Add Hysteria outbound & transport (version 2, udphop) and Salamander udpmask#5508

Merged
RPRX merged 66 commits intoXTLS:mainfrom
LjhAUMEM:hysteria2
Jan 13, 2026
Merged

Proxy: Add Hysteria outbound & transport (version 2, udphop) and Salamander udpmask#5508
RPRX merged 66 commits intoXTLS:mainfrom
LjhAUMEM:hysteria2

Conversation

@LjhAUMEM
Copy link
Contributor

@LjhAUMEM LjhAUMEM commented Jan 9, 2026

基于 44a5643

已测试可正常连接 hysteria2 v2.7.0 服务端。

二进制体积变化:

  • windows/amd64: 31.9 MB → 32.3 MB
  • linux/amd64: 33.0 MB → 33.4 MB

完整配置示例:

{
  "log": { "loglevel": "debug" },
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 1080,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "hysteria",
      "settings": {
        "version": 2,
        "address": "example.com",
        "port": 1081
      },
      "streamSettings": {
        "network": "hysteria",
        "hysteriaSettings": {
          "version": 2,
          "auth": "Se7RAuFZ8Lzg",
          "congestion": "brutal",
          "up": "100mbps",
          "down": "100mbps",
          "udphop": {
            "port": "20000-50000",
            "interval": 30
          }
        },
        "security": "tls",
        "tlsSettings": {
          "serverName": "example.com",
          "allowInsecure": true,
          "alpn": ["h3"]
        },
        "udpmasks": [
          {
            "type": "salamander",
            "settings": {
              "password": "cry_me_a_r1ver"
            }
          }
        ]
      }
    }
  ]
}

@RPRX
Copy link
Member

RPRX commented Jan 9, 2026

不是从 fly 搬过来的吧,它那个好像有点问题

@LjhAUMEM
Copy link
Contributor Author

LjhAUMEM commented Jan 9, 2026

不是从 fly 搬过来的吧,它那个好像有点问题

不是,但参考过,还参考了之前删除的 quic 传输层

@RPRX
Copy link
Member

RPRX commented Jan 9, 2026

似乎有一些 hy2 实现没有实现端口跳跃和 obfs,这个 PR 实现了吗

@LjhAUMEM
Copy link
Contributor Author

LjhAUMEM commented Jan 9, 2026

似乎有一些 hy2 实现没有实现端口跳跃和 obfs,这个 PR 实现了吗

obfs 实现了,端口跳跃没有,端口跳跃我需要再看下

@RPRX
Copy link
Member

RPRX commented Jan 9, 2026

根据 https://t.me/projectXtls/1354 的想法,obfs 应该用一个新的层,顺便加个新的层吧

@Fangliding
Copy link
Member

我觉得加个传输层没有用 不如都写hy setting里

@RPRX
Copy link
Member

RPRX commented Jan 9, 2026

既然加进了 *ray 就按 *ray 的架构来统一处理吧,毕竟 TLS settings 也得复用

@RPRX
Copy link
Member

RPRX commented Jan 9, 2026

就是说既然无法在一个地方全部写完就按功能分开吧,并且 obfs 是作用于 QUIC 外部的,写 hy2 settings 里也会很怪

@LjhAUMEM
Copy link
Contributor Author

LjhAUMEM commented Jan 9, 2026

就是说既然无法在一个地方全部写完就按功能分开吧,并且 obfs 是作用于 QUIC 外部的,写 hy2 settings 里也会很怪

往 StreamSettings 加个 networkMask 字段吗还是

@Fangliding
Copy link
Member

Fangliding commented Jan 9, 2026

没有协商这个传输就对其他协议没作用 这个obfs也是hy专有的 没法重复组合的东西放外面没啥用
TLS setting是个结构体可以复用

@RPRX
Copy link
Member

RPRX commented Jan 9, 2026

总不至于往 proxy 的 hy2 settings 里加个 TLS settings 吧,那太怪了

既然不动 TLS settings,obfs 留在 hy2 settings 里也是很怪,万一有人 PR 个 hy2 服务端过来,obfs 不就可以给 XHTTP/3 用了吗

@toyo2333
Copy link

toyo2333 commented Jan 9, 2026

等等,这是出站? 那xray服务端会支持建立HY2入站么?

@RPRX
Copy link
Member

RPRX commented Jan 9, 2026

@LjhAUMEM 我想一下,按照 streamSettings 内目前的规律是 network、*settings、security、*settings

所以为了直观展示层级关系可以叫 endmask、*settings

@RPRX
Copy link
Member

RPRX commented Jan 9, 2026

至于端口跳跃,可以先不实现,毕竟加 hy2 主要是防止 Xray 被一开始就排除在选项外,端口跳跃特征太明显了也蹦跶不了多久

@Fangliding
Copy link
Member

为什么bps定义了一个解析回头把错误忽略了 然后好多地方全忽略输出不直接写 写一堆 _ =

@LjhAUMEM
Copy link
Contributor Author

LjhAUMEM commented Jan 9, 2026

@LjhAUMEM 我想一下,按照 streamSettings 内目前的规律是 network、*settings、security、*settings

所以为了直观展示层级关系可以叫 endmask、*settings

好的我看看

至于端口跳跃,可以先不实现,毕竟加 hy2 主要是防止 Xray 被一开始就排除在选项外,端口跳跃特征太明显了也蹦跶不了多久

啊 刚看完端口跳跃 不过也可以别的 pr 再加

为什么bps定义了一个解析回头把错误忽略了 然后好多地方全忽略输出不直接写 写一堆 _ =

当时想的是 0 也可以直接用,但是这样看不到解析的错误,我改一下

@LjhAUMEM
Copy link
Contributor Author

LjhAUMEM commented Jan 9, 2026

端口跳跃其实也可以抽象成一个 endmask 给所有基于 PacketConn 的客户端使用,在想解析的时候是不是可以做成数组或者增加一个优先级字段实现嵌套 wrap,明天再看

@LjhAUMEM
Copy link
Contributor Author

LjhAUMEM commented Jan 10, 2026

应该可以了,endmask 先加上了 hysteria2 会用的两个,其他的可以另开个 pr 加,如果有兼容问题再看

不对,udphop 好像需要持续获取新的 socket,好像还不能这么改

@LjhAUMEM
Copy link
Contributor Author

LjhAUMEM commented Jan 10, 2026

udphop 需要实时监听新的 socket 还是不能加入嵌套,预计 streamsettings 加入三个字段,endmask,*settings,endmasks,前面两个作为单独的选项给最外层比如 udphop,endmasks 作为可选嵌套伪装,但感觉不是很好,先实现看看

还是只保留了数组的那个字段,如果存在 udphop 不加入嵌套,单独使用,好想删掉 udphop

@LjhAUMEM
Copy link
Contributor Author

我这边没问题了,不知道 rebase 对没有 改成数组好像也支持单个解析

@RPRX
Copy link
Member

RPRX commented Jan 13, 2026

改成数组好像也支持单个解析

再检查一下吧,我在写 release notes,半小时后发版

@RPRX
Copy link
Member

RPRX commented Jan 13, 2026

最终伪装层早该加了,不然这一块那一块的,下个版本可以把 fragment/noise 移到最终伪装层这里,然后把 KCP 那些也移过来

@LjhAUMEM
Copy link
Contributor Author

再检查一下吧,我在写 release notes,半小时后发版

又不行了,难道是我刚刚没保存 json,现在是只能解析数组

@RPRX
Copy link
Member

RPRX commented Jan 13, 2026

然后再加上 ICMP 和 ASCII,把这些搞完给你一个 Project X NFT

@LjhAUMEM
Copy link
Contributor Author

然后再加上 ICMP 和 ASCII,把这些搞完给你一个 Project X NFT

wireguard 的 icmp 吗,ASCII 是啥 那个数独协议?有空我可以看看,但不一定有能力完成

@RPRX
Copy link
Member

RPRX commented Jan 13, 2026

不是,是把 UDP 伪装成 ICMP

ASCII 那个更简单就是映射成可打印字符就行

@LjhAUMEM
Copy link
Contributor Author

有点类似 hy1 里的 faketcp,都是直接构建原始套接字,需要 root,但 icmp 应该比 tcp 简单

@RPRX RPRX changed the title Add hysteria2 outbound Proxy: Add Hysteria outbound & transport (version 2, udphop) and Salamander udpmask Jan 13, 2026
@RPRX RPRX merged commit 92ada2d into XTLS:main Jan 13, 2026
38 of 39 checks passed
@RPRX
Copy link
Member

RPRX commented Jan 13, 2026

感觉 finalmask [] 然后里面填 net tcp/udp 也行,算了各有所长吧

@Fangliding
Copy link
Member

噗 写到那里的时候有事被摇走了 回来的时候没弄上 那个字符串应该是copilot tab自动补的我没来得及改 我还记得回来要改一个时间 估计是看到 maxIdleTimeout 那里去了

@birdofprey
Copy link

1.PaaS架构是一种稳态架构,符合大道至简原则。 PaaS是个终极架构,上管应用,下管硬件。系统的天然分界平面,说的再简单一点,这套架构才是最简单的工程化部署实体。同时,落地需要企业或者运维团队形成真正的技术能力才行。k8S以及OPENSTACK确实表现出了蚁群智慧的工程设计方法,传统意义上的计算机已经开始向蚂蚁模型演进了,数据中心才是更大的智能体openstack是事实上的规模化分布式应用层集群系统参考实践模型,如果OpenStack是OSI/ISO七层模型,那么K8S就是TCP/IP协议栈。毋庸置疑,它们最终会互补成为一套更棒的标准体系和规范。关于K8S,我觉得目前最主要的限制是没有像Debian Gnu/Linux那样的本地源系统支持很好的本地化全功能部署和实践能力。导致用户上手实践困难。做好了本地源ISO镜像的发布将是社区成长的一大利好。企业应该有自己的Docker仓库系统,第一、有利于企业应用的统一化封装;第二、有利于企业应用系统部署过程中的Docker镜像包应用系统的网络层面及应用系统层面的安全管理和控制;第三、有利于企业代码审计,第四、有利于企业自身数据资产的收集和积累。这样的仓库系统有一套自由开源的实现,那是一种容器化的重要演进里程碑
2.当年的互联网是善良人设计给善良人用的高级工具。然而人性是复杂的。所以从今天起,用户有权利保护自己的数据资产安全。而且应该是必须的。善良不该成为被肆无忌惮的进行偷窥和信息隔离的受害者。不知道私有云的重要是因为还没有意识到自己的数据资产是什么的那群人,企业未来应用层节点的多活态将是一种常态。这是降级运行的先决条件。TLS并且能支持自签名是企业数据安全之本
3.Gnu/Linux是个巨内核,但它是模块化的。网格计算会以节点为基本单元,模块化可以让节点以功能为单位进行方便的组装和传递。Docker确实正在成为更高级的软件服务组件封装和发布方式。但缺少本地化自主管理工具。Debian Gnu/Linux是否考虑过发布一个离线的imagesa组件镜像ISO功用户自由创建本地源并开始普及使用,更大的社区才会有更长的长尾,根本就不需要所谓的专利保护,自然演化的长尾理论很容易就可以让开放系统受益。
4.架构设计和测试中应该定义一个新名词:双螺旋完备性测试。这个概念来源于生物学概念"双螺旋"。设计需要这样一个协议支持横向自动扩展。适用于各个层的普世协议,就像DNA双螺旋结构那样,那高可靠性将是数量级提升。比如网络层有VPC,我理解就是一种架构双螺旋。但VRRP协议应该不算,主备模式浪费了一半能力。ORACLE的RAC也可以理解为架构双螺旋。但自由开源比较缺少这种通用架构或者通用协议,或者说架构设计中应该定义这些内容,一方面为降级做好准备,一方面为横向扩展做好准备,并能通过形式化验证,具有良好的工程化方法实现。这样架构就有了彻底的单点故障消除和降级运行能力。没有双活哪里来的降级运行,在当下数据流实时性和相关性越来越紧密相连的模式下。很多应用系统单点故障带来的故障MTTR时间过长应用是无法接受的。或者换个说法,用户作业过程是无法接受的。 IEEE缺少一个自由的类似VPC的垮设备多链路捆绑协议。 嗯,是这样的。但是目前IETF确实没有一个vrrp协议的升级版。第一是无法解决1/2浪费问题。第二厂家设备之间无法使用通用协议进行这种设备间的堆叠配置。第三没有这样的自由开源第一跳协议也让集群系统的多机并行结构复杂而且价格超高,不利于技术的真正普惠世界,不利于物理层的双活螺旋结构化演进。如果能在802.1aq中加入一个自由的垮设备链路聚合和捆绑协议,或者HeartBeat是否可以演进到一种双螺旋结构模式,或者结合ETCD来一个完全多活模式的集群系统架构呢??!!  那将普惠整个网络世界。只有有了这种网络层的双螺旋结构,硬带宽问题才能真正走向并行扩展。有了这样的基础设施,如果我们的分布式节点间通过双冗余高速网络将同步控制在亚微妙级,CAP问题还会存在吗??!!或者说我们能不能通过另一种思路把CAP问题转换成另一种形式的问题。
5.精简指令集加上大内存,应该可以很好的抵消不断的需要读取指令带来的CPU时间片浪费。
云计算偏离了“呈现时间”的问题。而呈现时间主要表现在客户端系统性能上,因此而言,对等计算模式更全面和完善。
6.随着第一跳应用网关冗余技术的日趋成熟,网络正在以一种新的方式重生。P2P管道可以让节点之间形成新的计算能力和应用集群。边缘设备将在应用层形成新的网络和计算能力。无服务器模式将越来越多的被对等集群替代。边缘计算技术向数据中心渗透后,数据中心会成为网络的中枢神经系统和流量导向器,基础网络设备和计算节点故障将更趋日常化。数据中心将逐步抽象成一个由例如K8S或者OpenStack工程化的逻辑性实体。
7.生命体中,单个活体细胞并不能产生那种群体活体细胞群集所产生的特性。从架构的视角看,群集才是一个整体,单个活体细胞只是一个模子。类比计算集群系统,单个计算节点就是模子。只要逻辑上群集有效,模子并不重要,模子群里模子死亡更迭是进化的必然方式
8.大道至简原则就是世界的基础规则之一。所有的系统崩溃都源于复杂度带来的熵增混乱。从这个角度看,好系统都是更少的使用性能换取更高的效率的系统。当然自由本身也很重要,它让自由软件本身不断的快速普及和发展。如果事情变得复杂了,那一定是哪里出了问题。
9.7x24小时应该和硬件故障无关;或者换一个说法,系统在架构设计上应该满足即使某一功能模块节点故障也不会导致应用服务终止。事实上所有的IT企业都没有所谓的一个集中数据中心。他们都是有几个或者更多的数据中心。架构上的分布式是演进的比如方向,结构上分布式有利于更好地对抗不确定性以及规模化带来的技术管理成本,分布式架构本身是模块化思维的规模放大范式,这点可以确定。企业管理上的统一性本身和架构的分布式本身没有什么关系,一个是企业整体管理行为,一个是IT技术架构。架构上的分布式不等于管理上的各自为战。集中管理是一种管理组织行为,分布式是一种系统技术组织行为,两者本身可以和谐统一的。
10. 大道至简是真理,进化中最后灭亡的都是自我复杂度大于了自身的管理成本带来的系统崩溃。多活节点值得研究。第一跳网关冗余协议能否演进到全多活并行集群态,将是边缘计算对网络的基础性需求。没有这样的第一跳网关层,边缘计算对等体网络将无法保障其可靠性以及健壮性要求。服务网格也是不可靠滴。应用不可靠,本身就已经是一种失败。能实现多主机多活态单VIP分布式集群或者并行集群,那将是计算机系统架构演进的重大里程碑
11.SRE的重要理念就是要让故障日常化,应用服务永久在线;物理层实现多活,应用层可降级运行,各个服务模块间分布式并集群化。
12.如果我们不断使用全链加密的方式传递信息。那信息在多次传递中产生的信息熵增就可以让破解难度成指数级增长。网络嗅探基本就算是失效了,我们可以把它称为多节点的流式加密,这样加密强度足够高。现在问题是如何防止节点被击穿带来的内部结构垮塌,网络其实更应该像蜂巢那样,每个节点六个方向,并在每个方向上用自己的边长数。每一个节点就是一个,维护六个方向键,形成一个蜂巢穴。蜂窝即使被击穿。内部结构会有损毁,但整体结构不会垮塌,算法里是否可以加入一种信任危机权重。比如在节点维护的多个出口方向中有意驱逐长时间的链接,然后随机选择其它节点建立连接。避免长期信任节点带来的上游信任节点被击穿引发的下游节点损失。也是防止节点被击穿带来的内部结构垮塌的一种思考。
13.所有的应用需求最后都需要落实成硬件的性能消耗。所以我一直觉得用户侧的本地化功能强大同样重要。实际上也是这样。就连我们的手机都是一直在提升计算性能的路上。 边缘计算本质上就是对等计算的延伸。本地化功能强大是必须的。网络带宽再充足,它也是珍贵的,它本身一直也无法面对正在的不确定性因素 自由使用是商业价值的第一步,没有自由使用,软件系统整体上会产生用户数过低。低于某个度的时候就失去了普适性,然后恶性循环开始。软件系统很快就走向衰落消失了
14.如果站在用户侧思考"0信任网络"的概念,用户对所有的网络接入也应该是不信任的。由此我们需要第一方隔离原则。就像高速公路一样,我以符合高速公路的安全要求为标准开车上路,但我也可以采取良好的第一方隔离原则建立以自我为中心的0信任用户体验。 如果网络是高速公路的话,基于这种网络的通讯就像在高速公路上开汽车。建议用户一定要把自己车上的集装箱搞得结实些。因为在这样的高速公路上你不能避免其它车辆不碰撞你,也无法避免很多不确定的因素不会影响你的车辆。如果集中箱不够结实,那因此产生的货物泄漏真是太不幸了,高速公路上我们要确保的是自己不翻车也不被恶意伤害。战场上最好的防护就是战士的自我反应;同理,网络上最好的防护就是节点的自我IPS能力。
15. 其实Linux这28年来确实促进了很多新技术的诞生和普及,利益总是存在,但不是以牺牲通用性和普及度为代价滴。 没有用户普及度的系统基本都将被市场和用户边缘化直至淘汰。一个良好的自由开源社区正好为系统保持良好的普及度聚沙成塔效应。随着内存容量的不断扩大,内存计算已经在成本上逐步开始走向成熟期,tmpfs文件系统可以发挥更大的作用,中间结果不需要产生IO消耗。希望Gnu/Linux更先进,当然自由开源演进本身可以让更多的新特性被引入并进行广泛的测试体验。Debian Gnu/Linux,CentOS为Gnu/Linux的通用性和普及度贡献巨大。
16.实际上所有边缘设备的计算能力一直在提高和升级。。。分布式对等无处不在
17.如果全世界都使用某种动态数据交换协议,很多用户侧节点手拉手,这种协议不提供所谓的服务,但可以进行数据交换,并作为BGP协议的增强附加部分。是否可以更好的保护用户数据和隐私。
18.CEPH在算法上领先于时代。易用性再有所突破那将是存储网络化的必然。从本质上来说。CEPH的逻辑符合大道至简原则。社区的上边才是企业,这点Ceph守住了。像Oracle那样心怀鬼胎的厂家社区里很多。所以人家RedHat等公司不是又搞了个倾向于GPL V3的软件授权备忘录吗?其实对社区贡献的多少,用户是能看到的。从系统的普及度就能看出来。自由的软件分发模式给软件企业带来了更大的市场利益。。
19.良好的社区可以保持软件系统进化需要的最少种群数量和用户热度, 自由开源协议很重要。协议本身是一种内聚力,同时也是一种契约,更是一种外部演化力。没有协议或者协议含糊,最终商业公司系统性污染很容易让自由开源系统成为商业利益的牺牲品。软件发展史中,这种事不胜枚举。自由开源软件的好处,第一,可以让软件具有更长的生命期,第二,可以在演进过程中自然淘汰一些看起来很好但未必真正能成熟的应用需求和演进方向
20.路由节点组成的数据链只要能抵抗子弹穿透带来的空腔效应那就是世界上非常先进的协议。如果每个节点上都散播更多不确定性,会不会更好的起到保护节点和有效信息的效果。路由节点建设应该就像风吹过沙上写的字,风是信息,沙是节点,事实上我们可以让数据在每两个节点间都使用不同的端口,协议以及加密方式进行通讯。结合类似SDN的规则下发机制应该可以让这些事自动化.IETF是不是可以做些这种技术的尝试.
21.Gnu /Linux 以及安卓系统能不能有一套一致的沙盒系统,用户密码输入错误定义的次数沙盒就初始化,用户可以将需要的软件打包离线存储在别的地方,用户定义时间段内不使用,沙盒自动销毁。当下隐私保护很需要这些功能特性。Tor完全可以模拟码分多址的原理,在当下Tor的基础上实现一种类似扩频通讯的数据加密解密过程。
22.大二层之后,第一跳网关在数据中心间的动态漂移该如何实现,或者第一跳网关层如何部署与多个数据中心间形成逻辑第一跳网关层是个问题。
23.之前不太了解IETF,了解以后才知道他们的标准是可以实践的标准,是通过具体实现支撑的标准。所以很期待IETF能通用SD—wan出台。所有不开放的标准最终都是套在用户身上的乾坤圈,都是用户肉肉的利器,都是垄断利益和阻止技术进步的人为壁垒,都是以自由的科学阻断科学的自由

@birdofprey
Copy link

24.自由是关于每个人的,我们必须防范数据纳粹的数据独裁,这数字纳粹本身可能比社会纳粹更可怕,计算机科学家们应该为防范数字纳粹化做些事情。数字纳粹化比数字犯罪可怕的多,虽然数字化可能被用来犯罪,但那绝不是说数字纳粹化就是为了防止犯罪的正当理由。
25.网络中每一个节点都可以运行一种类似于信使的程序,只传输中间数据包给自己的上下游节点,这样的信使越多,对于每一个个体来说通讯环境越自由安全。信使偷窥信件本身就是一种非法。为了确保这样的功能,每一层的数据对于其它层都应该是透明的。或者换个说法,一个层的数据片段对于其它层是无意义的,能不能实现这样一种机制,A节点,B节点打开一个端口但并不跑数据,只作为一种签章端口,第一次连接并通过这个端口交换私钥后该端口就关闭,之后数据交互进入端口随机化过程。直到本次所有数据交互完成。这样是不是可以最大限度的避免端口特征
26.首先需要一个本地化的独立的应用软件来支持。不想要那种天天在线更新 更新 更新 下载 下载 下载的玩意。。我们要的是工具,不是拴着链子的工具。自由演进和开放的社区环境可以很好的阻止和延缓“鸿沟理论”的效应。所以良好的软件生态是社区化基础之后的特定私有用户服务。Debian Gnu/Linux社区的演化就是很好的例子。而像Oracle那样扼杀自由开放的方式是一种信誉体系的崩塌。软件授权就是一种承诺,是一种对未来演化的承诺
27.第一跳才是自由的入口,没有良好稳定的第一跳层和协议以及保护协议。那剩下的一切再好也是没有意义的。第一跳崩溃的直接后果就是应用的停摆,其它层次上再好的双活多活设计对应于来说也是无事于补。
28.架构的自由加上社区的内聚力和外向性演进可以保证一个社区不至于演进的太散而分解,也不会至于因为太过封闭而自我消亡。
29.截获了1和5,但通过乱序、加密、 多路径的保护,没有截获到2 3 4其中的一个。那信息片段依然无法拼成一段信息。信息本身就是安全的。。。
30.自由是所有语言的基本特性,因为她最终体现了思考,是思考的形式体现,限制语言的自由就是限制思考的自由。思考可以引导,但绝不应该限制
31.脑袋再聪明,手无缚鸡之力,有什么用?系统性思维教会我们,一个系统的能力是所有系统组件组成的整体性能力的集合。边缘计算弥补的就是缺失的手的能力。
32.双向门机制其实更好的实现了信息多渠道隔离交互。双向不同渠道注册和发放码元,除非能同时截获,密码和密码本同时发送,但通过不同信道,同时截获带🈶TLS,没有上下文积累的数据包,破解还是很困难的,不过这一想法需要数学上的一个验证。
33.“0”信任网络首先体现在主机侧应该具有自主的主动防御能力和第一方隔离能力。IPS应该是一种计算机系统应该具有的普遍能力,而不是一个设备。系统的防御性设计需要进入场景化设计规范,传输层加密应该成为基础设施的基本能力。
34.没有完整自举的本地源系统部署和功能是很多所谓云原生系统的硬伤,就像无法剪断脐带的婴儿。如果一个人被砍去手脚或者切断手脚的神经系统,他的大脑就是再超级,也无法让他完成很多具体的事物。同理,一个完善的系统也不仅需要一个大脑,同时需要健壮的信息传输系统以及与大脑能力匹配的边缘系统来发挥系统性的能力
35.交叉验证是个好办法。可以防止节点的不断异变带来的整个系统网络的系统性污染,每一个节点都是一个巢穴,每一个端口都是一条边线,千万个第一跳诞生并形成规模化层蜂窝结构,实现面向用户连接的负载均衡器能力,多节点服务均化水流,避免大流量带来的节点暴露和流量统计突出问题。
36.降级运行是一种机制,就像所有车都有刹车系统一样,既要保证系统在正常运转时候的高效,又要保证系统进入某种灾难过程避免造成彻底的“车毁人亡”。这种机制既可以是一套技术能力和方案设计部署,又可以是一套制度化流程化管理组织方式。要具备这种降级运行的能力,系统的设计初期就需要保证各个层面具有降级运行能力。降级运行概念的核心就是最大限度保证服务的连续性,局部问题不会引发系统性全局恐慌。
37.科学和达摩克利斯之剑一样,是双面的。一定要保证我们首先是为了捍卫自由。因为,为了安全交出自由,最后既得不到安全也将失去自由。 自由很珍贵,所以要珍惜。 在你拔出利剑之前,一定要先学会自律
38.首先定义一下通信链:它是指在端到端或者点到点的通信链路上的可信节点组成的一条通信通道。通信链上的节点可不可以完全启用一条链路上两节点间或者节点组群的双向门验证,同时提供一种选举机制,对于长时间信任的节点进行解散并重新选举建立互信关系。避免长时间信任某个节点而带来的依赖粘性造成单一节点被控制产生的信任雪崩事故,这一过程我们可以定义为创建安全链。第三方也有不可信的时候,为了避免信任粘性出现的过度信任灾难,可信第三方采取不定期权威选举机制是不是更安全一些。
39.计算机的大并行集群分布式应用和技术就是一种复杂系统。需要很高的技术和系统性组织技术才能把小模块组织成一个有效系统。
40.网络节点的信任清洗,在可信网络节点间应该设置一种认证协议,随机性对可信节点进行信任度归零并重新开始建立可信度,这种协议应被限制在控制层面,并适度影响随后节点的数据层面,举个例子吧,如果A节点之前是可信的,在控制层面进行信任度归零后,该节点数据层面当前通信直至正常结束后将不受影响,网络内随后的通信流量将选择可信度更高的节点进行。这样可以更好的避免全网内某一节点被掌控后的流量统计分析和审查。
41.信任驱逐算法,网络是不可信的,本着这一原则,我们将零信任原则用于节点到节点的认证和可信过程来完成信任清洗。在多节点通信形式的网络中(如OSPF、BGP或者其它形式的多节点逻辑层网络),我们可以引入一种信任驱逐机制,在该机制中没有永久的可信任节点,信任是临时和动态化的。节点双方的互信通过可信值度量(可信节点表中记录节点和对应可信值),可信值和时间相关,之后对高可信值条目在随机时间点清零,可信值进行重新刷新,这一过程中会有高可信值节点被重新初始化。信任驱逐会带来当前节点与它建立连接的高可信值节点数据传输中断,但具有高可靠值得节点被驱逐后,节点依然可以通过其它可信节点续传。从更高的层面看,数据传输是连续的,可信的。
42.sre运维团队建设,大数据应用让信息系统间数据依赖关系越来越强了,哪个环节掉链子都影响整个大系统服务质量。最高级的运维就是让故障日常化,但服务连续性是不受影响的,现在很多并行系统上去并行了,但是不敢拆。要解决这样的问题需要更好的分布式并行集群系统和技术规范作为支持,同时要让故障日常化处理不影响业务数据流也是需要并行机制替换故障设备这样的机制。
43.对抗窃听和窥探最好的方式不是专线,而是真假信息混合后带来的信息熵增,最大限度的信息不确定性就是最好的保密性。切断一切连接,那样的阻断有什么意义,我们如何让我们的有用信息经过🈶噪声和干扰的信道传输才是通信原理的本质。香农大爷的信息论其本质就是我们如何让我们的有用信息经过🈶噪声和干扰的信道进行安全的传输。因此智者修桥,愚者断路。没有信息的传播如何主张自己的观点,如何博得世界的理解。长远上来说 这是舆论战略上的大失败
44.什么时候开放协议vrrp 才能进步到并行化集群模式。作为一种更高级的第一跳协议,更好的提高设备效率,更有效的保障业务系统的连续性,我们应该在每一层上做好冗余协议的设计和实现。只有解决好了每一层的冗余,系统性的冗余才能得到彻底的根治。奥卡姆剃刀原理还是很有用滴

@birdofprey
Copy link

45.安全的本质是人性,所以恩格马加密机最终败给了炸弹破解机。机器都可以是自动化过程,但这些都源于人的设计,以人性对人性,善良的心最终取胜,多级代理,分段加密,分段TLS自签名证书。一种软件化的恩格马加密机就实现了,最重要的是它突破了不能将加密信息加密成自己的限制。
46.自由开源的软件协作,很多社区的反馈即有问题反馈又有新的需求想法,本质上这就是一种最好的问题建议收集和新需求收集的零成本方式。
47.换乘站和桥都很有意思。不过我觉得换乘站有四又三分之二站台会很好玩。那样的换成站可以通往任何地方
48.如果一个地方制造了更多的信息阻断和欺骗,造成了更多信息不对称。那肯定就是专制或者专权的地方,平凡的邪恶。这是一种统计学规律。自由本身就是科学精神的一部分。至愚者断路,至智者修桥,这是一个人对世界的两种态度,而这种态度可以通过做事的整体过程体现出来!!!再伪装也没有用
49.协议标准应该才有开放式的,但数据一定要进行加密。A把球传给B,b可以选择射门也可以选择传给C,谁知道呢。除非你一直追逐球的轨迹。假如节点是一道门,如果推开每一个门都是未知的不确定性路线。这样门越多信息熵就越大。
50.自由软件的本质是软件自身自由的问题,开源软件的本质是软件使用自由的问题。就像鸟的自由和养鸟人的自由的区别一样
51.如果我们把云计算环境比喻成一个胃,那我们用户的系统就像是胃里的一颗豆子。从0信任的纬度去思考。为了保护豆子不受胃酸以及消化液的侵害。我们应该给这颗豆子套上一个胶囊保护壳,并且让豆子检测壳的状态,一旦壳破裂,豆子将自我融化。网站里边或者操作系统里边应该预埋一个只有你自己知道的探针模块。一旦有人动力系统就自动保护进入网络限制或者断网模式。这样如果应用节点很多的话其实一两个离线不会影响业务,但运维系统是可以发现这些机器离线的。不耽误应用也可以及时发现问题,然后再登录系统进一步排查问题。从数据安全的角度看,云主机应该具有自我销毁的能力
52.你玩过打地鼠游戏吗?地鼠洞足够多,那除非毁了这个游戏机。否则打着地鼠的概率永远比地鼠探头的概率小。探头不一定就往出跑。那样打到真真往出跑的概率应该更小
53.设计巧妙比精密重要。这是增强系统强壮性很重要的措施之一。太精密必然复杂,增加的是控制成本,一旦控制成本太高,那就是压垮系统的一块巨石。具体实现上的巧妙则更是珍贵的东西
54.如果把TLS端到端想象成一根管子,我们可以在管子里套管子。如果是多层管子就需要每一层都需要进行焊接,这样其实多层套管的套管焊接部分也就最薄弱。其实也就多次加密的节点最薄弱。需要想办法组织好每一层管子的焊接工艺。多层隧道,节点越多,层越多,追踪就越苦难,而且每一层可以使用不同的加密技术,重复发挥多层异构加密隧道带来的安全性。事实上我们并不需要一个明确的域名和IP地址的对应关系,需要的是通讯时链路端到端可用就够了,这种端到端越随机化,其保密性就应该越好
55.自由开源软件对于“数字自由”很重要。那么“数字自由”的另一面是什么,我认为可以叫做“数字纳粹”。是以美国为首滴通过技术对信息进行阻断,监控,窃听,伪造,进而达到对信息控制,筛选,隔离的体系化手段
56.之前的计算机应用技术假设的条件是系统肯定会故障,计算机系统自建设完成那一刻起就是走向故障的。由此为出发点,所有的系统故障都必然产生停机时间,也因此出现了各种故障灾备和故障迁移方案,不论运维还是灾备应急,一切围绕减小和缩短停机时间展开。对应用系统造成的影响也会被记成一种必然发生的事件。现在如果我们换一个假定条件:应用系统不应该出现对业务系统造成的停止响应。那么系统硬件的故障就是一种日常事件,硬件的故障隔离将于业务系统是否停止响应完全解偶,业务系统处于降级运行模式过程中业务可靠性得以保证。从这种假设出发,业务系统全链过程中每一层的双活结构就是设计中的充分必要条件。 智慧的背后是前端边缘模块的支撑,是系统间规范化的数据共享模块和接口普遍成熟,是数据流就像人体血液的自然流淌,是网络和业务系统全链过程中每一层的双活结构设计必然作为充分必要条件。 目前IETF应该抓紧定义一套双活结构协议,解决目前VRRP协议1/2资源浪费问题。
57.举个例子吧,比如我的ssh服务,默认是22,我连上以后改掉端口,这时候不退出是不影响我当前连接和数据交互,但其它SSH用户就需要使用新的ssh服务端口才能连上。当我退出后,下次登录就必须使用新的端口,改成一种通讯模式就是我的端口会在一次通讯或者一个完整通讯后,下一次会进行端口更换。或者在客户端定义一个端口列表,服务器端的服务端口在这几个端口跳变,同时计算机会开放更多的随机端口伪装成服务并作为数据黑洞,然后把真正的服务监听端口放在这里边。其它用户又不知道这个端口列表,靠猜是不是有些困难呐?我想光是探测这些端口也得花费不少时间吧。跳变的关键还是因为有了TLS 的成熟。如果按照之前的非加密传输,那端口跳变本身也就没有什么意义了。可以给不同用户组定义不同的端口序列,也可以给特定用户提供特定唯一的端口序列,这样除非用户把客户端程序给其他人 这个端口序列才会被别人知晓。然后服务器程序在监听开放端口时在这些端口内跳变。
58.安全多数时候就是障眼法。真正的安全不是对外在制度的惧怕和恐慌,而是对内在利益的发自内心的呵护和体贴。前者是一种应付和不得已,后者是一种自觉和主动性。
59.得考虑如何避免空间探测,或者让探测仪把F117看成是个小鸟。或者像U2的系统17,给探测仪一个镜像坐标。坦克的前面板有一个斜面的装甲层,这种装甲层可以造成子弹擦过之后产生漂移效应,从而无法击中目标。能不能在系统前置这样的类似系统,让探测行为得到的数据是无限熵增的,需要躲避雷达的技术,保护己方通信的安全性。想像一下,每个快递箱里边是真正的物品,快递箱开箱机制套上自毁装置,如果暴力拆箱则自毁装置启动。能有一套打水漂似的通信模型,数据在节点间就像打水漂那样跳跃。数据不是信息,它包含信息和噪声。一般意义上的收到了信息严格意义上讲应该是收到了消息,去掉噪声留下的才是信息。信息也具有时域性,有时候信息超过时间范围就会变成噪声。网络安全防护的两个基本点,一是时间纬度上的,二是空间纬度上的。在时间上要让恶意行为的等待响应时间趋近于无穷大;在空间上要让恶意行为获取的信息熵同样趋近于无穷大。这样的密级系统具有很好的系统可用性

@birdofprey
Copy link

60.不能排除有人利用安全软件本身来传恶意软件的可能性和实际存在的安全问题,不能说管理的集权化一定就愚蠢,但这的确为恶意行为软件提供了更高效和便捷传输的一种通道方式。
伪装成警察的坏人对社会和人民的伤害会更大,也更难于发现,比如1927-1937年大上海的警察系统。把它普遍化一下,伪装成集权化软件的恶意软件带来的隐患也更可怕,而且具有很强的欺骗性。集权化管理软件包括各种安全软件本身也是软件,是人编写的。
61.一个良好的业务信息化系统比然是业务体系的领导性支撑,技术体系的基础性掌控,业务需求的的先导性引领,技术团队具体化的保障。技术本身是要普遍支撑业务的,技术本身是因为需要才得以研发投入和推进,在自由开源社区这种演进可能更快。技术发展规律就是如此。随着积累带来的技术突破可以改变业务流程,那叫革命。
62.阻断别人本质上也会影响自己,阻断越多自己的空间越小
63.敌人永远都想知道的比我们多,敌人也会想尽一切办法避免我们知道的比他们多,这就是信息的价值。也是信息对抗的本质
64.一条路径,总是被包围和阻击的,好的加密通道应该像现实中的情报网一样,既要端到端安全,又要能够多条渠道并存。网状网络结构就是互联网最初为了避免出现电话网那样的局端单点沦陷带来的全局信息传递失效问题
65.在网络安全攻击恶意行为中,恶意用户首先会通过“踩点”“扫描”等正常访问请求进行大量信息收集行为,之后根据收集到的目标主机信息进行系统鉴9别、网站鉴别、服务鉴别,查找漏洞进行渗透利用等进一步网络攻击行为。信息搜集是网络攻击渗透的最重要的阶段,占据整个网络攻击的 60%,可见信息搜集的重要性。根据收集的有用信息,可以大大提高网络攻击的成功率。因此用户网站或者应用无意提供的系统有效信息都将成为恶意用户进行网络攻击的有用信息。网络安全攻击,敌人永远都想知道的比我们多,这种信息差就是信息的价值,也是信息对抗的本质。作为上线系统,如何增大无效信息熵,减小有效信息熵获知范围,是信息安全防护的两个层面,第一个层面可以通过信息
谣言来实现,第二个层面可以通过尽量少的提供系统有效信息来获得。系统应用上线前,用户通过必要的技术手段对系统版本、应用服务组件等进行系统信息隐匿处理,可以很好的避免系统向无关者提供有效信息,从而使得恶意用户在网络攻击第一阶段获得信息熵趋近于无限大,从而延长其信息筛选和处理的有效时长,有效减缓和避免直接有效信息告知带来的恶意攻击行为。
66.网络通信模型干嘛不加入随机端口机制,多个并发随机端口序列让流量更分散,信息熵更大
67.能不能在网络节点间实现一种特定功能,就像普通人交流的那种故意制造一个假信息并验证是否由特定信息接收者进行了泄密传播,从而验证节点的安全可靠性
68.所有的服务器软件,都应该有自定义端口的基本功能。所有的客户端软件也应该具有定义访问服务器端口的能力,这样才能让端口随机化,定制化。从而避免服务被猜解带来的有效信息泄露

@awamio115
Copy link

@birdofprey 黄龙江遍地带蓝牙.jpg

@fscarmen
Copy link

哥哥能一并支持一下 Hysteria 2 的入站?谢谢!

@hrimfaxi
Copy link

hrimfaxi commented Jan 25, 2026

这个版本的hysteria实现支持像原版一样关闭GSO吗?原版设置环境变量
QUIC_GO_DISABLE_GSO=1就可以关闭GSO。

参考

@LjhAUMEM
Copy link
Contributor Author

这个版本的hysteria实现支持像原版一样关闭GSO吗?原版设置环境变量 QUIC_GO_DISABLE_GSO=1就可以关闭GSO。

参考

可以的,都是相同的 apernet/quic-go

@LjhAUMEM
Copy link
Contributor Author

哥哥能一并支持一下 Hysteria 2 的入站?谢谢!

以后会的

@hedsbj
Copy link

hedsbj commented Feb 1, 2026

"version": 2,
这参数为何要设置两次

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.