Skip to content

xhttp h2c#5892

Open
Fangliding wants to merge 1 commit intomainfrom
h2c
Open

xhttp h2c#5892
Fangliding wants to merge 1 commit intomainfrom
h2c

Conversation

@Fangliding
Copy link
Copy Markdown
Member

#5093
顺便一提 一个失败的尝试 http.Transport 里设置h2c行不通 因为它强制尝试断言官方 gotls 的类型 不兼容utls

@RPRX
Copy link
Copy Markdown
Member

RPRX commented Apr 15, 2026

这个 PR 等 Xray-core 禁了公网未加密出站再讨论吧,每次看到 WS 80 VLESS 节点都很难绷

话说前段时间 @iambabyninja 在邮件中提到如果服务端 hosts 有把其它域名解析为 127.0.0.1 会导致绕过 block geo private

我的看法是可以在 direct/freedom 出站默认检测入站是否为 VLESS 等公网代理协议,是的话就默认 drop 发向内网 IP 的包

@Fangliding 有兴趣弄一下吗,给 direct 出站加个选项

@Meo597
Copy link
Copy Markdown
Member

Meo597 commented Apr 15, 2026

话说前段时间 @iambabyninja 在邮件中提到如果服务端 hosts 有把其它域名解析为 127.0.0.1 会导致绕过 block geo private

我自己设的是 IPIfNonMatch + block geoip:private
理论上应该无法 bypass

@RPRX
Copy link
Copy Markdown
Member

RPRX commented Apr 15, 2026

还有这个 https://t.me/projectXtls/1948 ,Socks5 UDP 改为标准实现吧,每次都监听个新端口,只允许第一个来源二元组的包

@Fangliding
Copy link
Copy Markdown
Member Author

Fangliding commented Apr 15, 2026

这个 PR 等 Xray-core 禁了公网未加密出站再讨论吧,每次看到 WS 80 VLESS 节点都很难绷

话说前段时间 @iambabyninja 在邮件中提到如果服务端 hosts 有把其它域名解析为 127.0.0.1 会导致绕过 block geo private

我的看法是可以在 direct/freedom 出站默认检测入站是否为 VLESS 等公网代理协议,是的话就默认 drop 发向内网 IP 的包

@Fangliding 有兴趣弄一下吗,给 direct 出站加个选项

可以用内置 DNS 的 unexpectedIPs:["geoip:private"] 屏蔽 自动滤除内网IP的响应

@Fangliding
Copy link
Copy Markdown
Member Author

Fangliding commented Apr 15, 2026

当然 IPIfNonMatch 也是个很不错的选择

@Fangliding
Copy link
Copy Markdown
Member Author

Fangliding commented Apr 15, 2026

还有这个 https://t.me/projectXtls/1948 ,Socks5 UDP 改为标准实现吧,每次都监听个新端口,只允许第一个来源二元组的包

没用 就之前那个本地探测的法子 大不了0~65535全部扫一遍 公网都不要多久 这还是在本地 最好的办法还是听在 127.x.x.x 上 不放在 127.0.0.1

@RPRX
Copy link
Copy Markdown
Member

RPRX commented Apr 15, 2026

IPIfNonMatch

这样的话确实能防一下,如果这里的解析遵从系统 hosts 的话

我的意思是 Xray-core 应该提供一个默认的防护,我感觉很多人根本没设置 block private 啊,比如 VLESS 入、direct 出就可以认定是服务端了,默认在 direct 出站 block private,加个选项主要是给内网穿透的内网端用的,@Meo597 有兴趣实现不

@Meo597
Copy link
Copy Markdown
Member

Meo597 commented Apr 15, 2026

这块的确是有点绕,用户不够友好,我自己玩内网穿透的时候抠了半天
我看下 direct 的实现,做起来应该很容易 毕竟 geodata 不是白重构的

另外对于中国用户,建议服务器端这样设置

{
  "dns": {
    "servers": [
      // 信任社区的非中国域列表,不再用ECS试探,尽管可能有中国的记录
      {
        "address": "8.8.8.8",
        "skipFallback": true,
        "domains": [
          "geosite:geolocation-!cn",
          "geosite:category-cas",
          "geosite:google",
          "geosite:google-cn"
        ],
        "finalQuery": true
      },
      // 其它所有域,先用ECS试探中国的记录,若无则回落以获取节点优化的记录
      // 此策略在权威和递归的缓存命中率低,试探结果用更长寿的乐观缓存可以减少RTT
      // 节点有Block CN策略,因此客户端只能用黑名单模式或带ECS试探的中国优先模式
      // 此策略旨在避免客户端粗糙的分流策略所导致的流量浪费和中国账号被风控问题
      {
        "address": "8.8.8.8",
        "clientIp": "218.2.2.2",
        "skipFallback": false,
        "expectedIPs": ["geoip:cn"],
        "serveExpiredTTL": 1209600
      },
      "8.8.8.8"
    ],
    "queryStrategy": "UseSystem",
    "serveStale": true,
    "serveExpiredTTL": 3600, // 1 hours
    "enableParallelQuery": true
  },
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "protocol": ["bittorrent"],
        "outboundTag": "block"
      },
      {
        "ip": ["geoip:private"],
        "outboundTag": "block"
      },
      {
        "source": ["geoip:cn"],
        "outboundTag": "block"
      },
      {
        "domain": ["geosite:category-cas"],
        "outboundTag": "direct"
      },
      {
        "ip": ["geoip:cn"],
        "outboundTag": "block"
      }
    ]
  }
}

@Fangliding
Copy link
Copy Markdown
Member Author

哦还有个办法 bind到eth0上应该也行

@RPRX
Copy link
Copy Markdown
Member

RPRX commented Apr 15, 2026

先发版了,月底应该再发一版,旧的内网穿透下个版本给它扬了吧,毕竟 XHTTP/3 也能 force-brutal 了,VLESS 没啥做不到的

@iambabyninja
Copy link
Copy Markdown
Member

Indeed, without proper configuration, we end up with the following issue, which affects a large number of servers.

Suppose we have some endpoint bound to localhost on the server, for example:

curl http://127.0.0.1:228/MySecretEndpoint

At first glance, it seems that if geoip:private is blocked on the server, the client shouldn’t be able to reach the internal network.

However, if we bind a domain, for example iamsuperhacker.com → A 127.0.0.1, and send a request through the proxy:

curl http://iamsuperhacker.com:228/MySecretEndpoint

…we end up with full access to the internal infrastructure (in this case, a localhost-only endpoint), if routing uses domainStrategy: AsIS.

The same issue can also occur with IpIfNonMatch, if the domain falls into a direct rule — for example, via a broad “.com” catch-all rule in certain configurations.

@Meo597
Copy link
Copy Markdown
Member

Meo597 commented Apr 15, 2026

在 direct 出站 block private,加个选项主要是给内网穿透的内网端用的,@Meo597 有兴趣实现不

我看一下 freedom 对象的生命周期,很快可以 pr

@RPRX
Copy link
Copy Markdown
Member

RPRX commented Apr 15, 2026

对了,还有 fragment、noise 下个版本彻底迁移到 finalmask,break 掉旧配置,已经有很多 GUI 客户端迁移完毕了

@patterniha 提过的是缺少啥来着

@RPRX
Copy link
Copy Markdown
Member

RPRX commented Apr 15, 2026

我看一下 freedom 对象的生命周期,很快可以 pr

那我先等一下再发版吧,话说 v2rayN 在非 Windows 平台上是 sing-tun->ss->xray,得提醒他们给 direct 出站加个参数

UDP 每个包都判断下 target 的话挺影响性能的,就判断第一个吧,本来也没啥 UDP 服务

另一个问题是服务端不一定有 geoip.dat,把 private 提取出来写 Xray 代码里吧

@Meo597
Copy link
Copy Markdown
Member

Meo597 commented Apr 15, 2026

我想的是我们提供设置,让下游自己去做默认配置
然后我们文档中内网穿透部分提醒用户

这样很容易在 direct block cn 或其它奇奇怪怪的需求

如果强行构造一个 private 并且默认封锁,感觉怪怪的

@Meo597
Copy link
Copy Markdown
Member

Meo597 commented Apr 15, 2026

比如说阿里云就喜欢用国防部 IP
我们内置的 private 毫无卵用

@RPRX
Copy link
Copy Markdown
Member

RPRX commented Apr 15, 2026

还有我看了下代码,VLESS 内网穿透内网端似乎没给 inbound 标 VLESS,要不标个 vless-reverse 正好可以绕过这个,XUDP Global ID 那里也加一下它

我想的是我们提供设置,让下游自己去做默认配置

下游行为不好控制,跑裸 core 的话更是没下游,加这个主要是给新手提供一个默认的防护,别安装个 Xray 把内网服务卖了

比如说阿里云就喜欢用国防部 IP

在阿里云上部署 Xray 也很有想法了,不过这个本质上还是 IP 列表齐不齐的问题,加上那些 IP 也不是不行,用户还可以自行配置 blocked IP 然后就采用用户配置而非内置列表,比如如果想关掉这个功能,填个 0.0.0.0 就行

@Fangliding
Copy link
Copy Markdown
Member Author

想要一个默认block 作为一个默认行为 然后有人要使用这个访问家里的私网(真实存在的需求)然后哦更新全部爆炸 还得去多填个配置
那下发给用户配置 90%的人不会注意到 这样又会引申出 那为什么不用上面的 dns 限制

@RPRX
Copy link
Copy Markdown
Member

RPRX commented Apr 15, 2026

要不标个 vless-reverse 正好可以绕过这个

算了还是标 vless 让它吃到这个 buff 吧,用户可能只是想反向代理而没有想内网穿透,默认严格些比较好

@RPRX
Copy link
Copy Markdown
Member

RPRX commented Apr 15, 2026

想要一个默认block 作为一个默认行为 然后有人要使用这个访问家里的私网(真实存在的需求)然后哦更新全部爆炸 还得去多填个配置

多填个配置而已,VLESS 内网穿透还没普及,不会炸很多

那下发给用户配置 90%的人不会注意到 这样又会引申出 那为什么不用上面的 dns 限制

又不是都走 Xray 内置 DNS,如果是系统 DNS 解析不就直接绕过了

@Meo597
Copy link
Copy Markdown
Member

Meo597 commented Apr 15, 2026

是的,我也觉得真的不合理!
我们提供选项就行,默认行为别改变

@Fangliding
Copy link
Copy Markdown
Member Author

多填个配置而已,VLESS 内网穿透还没普及,不会炸很多

其实很多人压根不用那玩意 家里有公网或者打个natmap出来这种才是主流

又不是都走 Xray 内置 DNS,如果是系统 DNS 解析不就直接绕过了

上面说的direct出站 只用指定domainstrategy就走内部dns系统了

@Meo597
Copy link
Copy Markdown
Member

Meo597 commented Apr 15, 2026

那下发给用户配置 90%的人不会注意到 这样又会引申出 那为什么不用上面的 dns 限制

主要是太烧脑了,DNS 和 ROUTER 都比较复杂
我为了封内网,把规则改来改去,牵一发动全身

@Meo597
Copy link
Copy Markdown
Member

Meo597 commented Apr 15, 2026

#5947

目前是没有内置规则的版本,确定要搞默认拦截我就弄
freedom 这块我完全不熟,需要谁来 review 下

@RPRX
Copy link
Copy Markdown
Member

RPRX commented Apr 15, 2026

要默认,这个重点还是“默认的防护”,和明文 HTTP 面板是一个道理,老手当然啥都懂,新手一上来就先埋雷几个月甚至几年

比如说你是个新手,本来用脚本的,想自己配置 Xray 了,这总得慢慢学参数,那刚开始几乎必然埋雷,把内网服务给卖了

@RPRX
Copy link
Copy Markdown
Member

RPRX commented Apr 15, 2026

甚至我有很长一段时间以为 *ray 本来就自带这个来着,直到写 VLESS Reverse 才确认了确实没有,好在服务端就只搭个代理

@Fangliding
Copy link
Copy Markdown
Member Author

这个 PR 等 Xray-core 禁了公网未加密出站再讨论吧,每次看到 WS 80 VLESS 节点都很难绷

主要是拿来平替 grpc 我稍微看了一下 stream-one 的情况并没有那么糟糕

@patterniha
Copy link
Copy Markdown
Collaborator

对了,还有 fragment、noise 下个版本彻底迁移到 finalmask,break 掉旧配置,已经有很多 GUI 客户端迁移完毕了

@patterniha 提过的是缺少啥来着

Just we miss noise "applyTo" option, to send proper fake-white-sni-quic-noise for ip4/6 when address is domain, because domain convert to ip after finalmask phase.(chrome use 1250 bytes for ipv4-quic and 1230 for ipv6)

Anyway, UDP and the entire internet in Iran are currently shutdown

RPRX pushed a commit that referenced this pull request Apr 15, 2026
…", "ext:") and apply a default safe policy (#5947)

#5892 (comment)

---------

Co-authored-by: 风扇滑翔翼 <[email protected]>
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.

5 participants