break source ?

按别名处理吧，不过如果用的人太少也不是不能 break

break source ?

@RPRX says "rename" not "alias", anyway I can set it as an alias, instead of replace.

OK, wait.

localIP 是在监听 :: 时，接受连接的接口(IP)地址？

yes, anyway localIP is useless.

那，再加个“没用”的： localIF 接受连接的接口名称😋

也不是完全 useless，万一有人想根据本机/非本机分流。。。不过它确实像 sourcePort 一样 useless

ok, I fix that, it needs some changes to worker, context,... This one takes more work.

so please wait...

ok, I fix that, it needs some changes to worker, context,... This one takes more work.

别名在配置阶段处理就行了

ok, I fix that, it needs some changes to worker, context,... This one takes more work.

so please wait...

i say this for fixing localIP.

Process it by alias.However, if there are too few people using it, it is not impossible to break it.

@RPRX

done.

fixing localIP, takes more effort, currently we only have Inbound-Gateway(interface-address) in the ctx, so please wait...

我在想要不别加 localIP，顺便把 sourcePort 删了，这俩实在没用。。。

多接口(网卡)用户，有用

我写 portMap 时也想了要不要匹配下 localIP，但感觉太复杂了，又没多少人会用到

Useful for users with multiple interfaces (network cards)

SourcePort is useful, for using Xray-core as an auxiliary program(I also use that before)

But for localIP users can set multiple-inbounds, for each interface.

@RPRX

it seems that, we can't access localIP for UDP in golang:

we only have one Addr and that is SourceAddr, so how can we get LocalAddr?

都存 ctx 里就行了，localIP 和 localPort 又不变，因为不同四元组会视为一个新的 UDP 流

如果你说你之前教过十年网络那我有必要怀疑伊朗的教育水平。。

可以理解，毕竟代理的情况，网络更加复杂，又是 source 又是 local 又是里面的 UDP source/target

I know that local IP for UDP is meaningless

but I say for UDP, localIP always remain "0.0.0.0", if we listen on "0.0.0.0".

so localIP only works on TCP, but this can mislead users.

就是说路由这里匹配的是外层 source/local 和内层 target，不是内层 source，虽然隧道的话内外层重合了

but I say for UDP, localIP always remain "0.0.0.0", if we listen on "0.0.0.0".

应该不会吧，比如 127.0.0.1 的请求，localIP 就是 127.0.0.1

so how can we get LocalAddr?

IP_PKTINFO

but I say for UDP, localIP always remain "0.0.0.0", if we listen on "0.0.0.0".

无论是什么协议，总会有接受“连接”(数据包)的接口

but I say for UDP, localIP always remain "0.0.0.0", if we listen on "0.0.0.0".

It shouldn't be, for example, for a request to 127.0.0.1, localIP is 127.0.0.1

??? here we only have one Addr and that is sourceAddr:

n, noob, _, addr, err := ReadUDPMsg(h.conn, rawBytes, oobBytes)

please speak english to understand better

还是路由文档里注明 localIP 的匹配只作用于 TCP 吧，反正这个就是附带的，这次主要想加匹配 localPort，因为入站能监听多端口，同一个 tag 不够用

Or the routing document states that the matching of localIP only works on TCP. Anyway, this is incidental. This time I mainly want to match localPort, because inbound can listen to multiple ports, and the same tag is not enough.

Ok, i will add for TCP, the rest is up to you.

then warn users?

Yes.
“路由”使用 localIP ，并且“入站”具有 UDP 监听，就在日志写入 WARN

话说我看 ML-DSA-65 公钥 base64 后是 2603 个字符，而考虑到备注有中文，二进制模式的二维码能存储 2953 字节（最低纠错）

所以还有 350 字节可用，REALITY password base64 加 VLESS UUID 占大概 100，那还有。。。

所以最低纠错的话，除了 XHTTP extra 应该不会炸，但 extra 的话感觉即使是 ML-DSA-44 遇到上下行分离也得跪

字节可不是字符啊

你再想想

英语的话一个字符就是一个字节，而且我看了下二维码只能用字节模式，因为字母数字模式虽然支持一些符号但不支持 &

@patterniha Ready 了说一声

wait one hour.

Ready

我想了一下 VLESS 加密不用 ML-DSA-65 做认证了，用 ML-KEM-768，服务端生成解封装 key 和对应的封装 key，后者只有 1088 字节由客户端配置存着，首次连接时把认证密钥密文和自己的临时封装 key 发给服务端，服务端用共享密钥加密或 hash 认证密钥发给客户端即可认证服务端的身份，要不要引入 x25519 我还在思考

@RPRX

I am implementing two feature:

1. targetDomainStrategy: AsIs/UseIP.../ForceIP.../ruleHitIP

"outbounds": [
    {
      "protocol": "any",
      "settings": {},
      "tag": "tag",
      "targetDomainStrategy": "ruleHitIP"
    }

2. fragment maxSplit

"fragment": {
          "packets": "1-3",
          "length": "10-20",
          "interval": "1-2",
          "maxSplit": "100-200"
        }

///

Both allow us to Remove an unnecessary ‍‍dialerProxy(or redirect-socks-in/out) and also give us more ability.

I open PR soon with full explanation.

When I wrote it, portMapI also thought about matching localIP, but it seemed too complicated and not many people would use it.

I do this, open PR soon.

When I wrote it, portMapI also thought about matching localIP, but it seemed too complicated and not many people would use it.

I do this, open PR soon.

别别别大可不必，按惯例一个端口对应一个服务是确定的，无论从哪访问，而根据 localIP 来分流会让所有人一头雾水

When I wrote it, portMapI also thought about matching localIP, but it seemed too complicated and not many people would use it.

I do this, open PR soon.

There is no need to be so cautious. Conventionally, one port corresponds to one service, no matter where it is accessed from. Diverting traffic based on local IP will confuse everyone.

the key can be 8888 or :8888 or 127.0.0.1:8888, or 127.0.0.1: or 127.0.0.1.

for doc:

we only put 8888 example in json example,

and put others in portMap explanation, so no one will be confused.

Xray-core must be perfect and cover all needs because it is the core!
and how it is used is not up to the core

如果这样的话当本地 IP/Port 符合多个规则时还有优先级的问题，总之就是很麻烦，不过可以区分 IPv4/v6

如果当初决定这么设计就直接 ":5555" 这样的语法了，现在又加了语法糖

priority issues

we can respect order when unmarshaling map json.

I've done this before: #4706

I still don't understand why that PR was closed

///

Anyway, targetDomainStrategy and fragment options is more important and i will do it first.