这不太好维护啊
如果比较有精力能否把已有平台上的bug修好(

这不太好维护啊 如果比较有精力能否把已有平台上的bug修好(

What does it mean?

Regarding the existing questions, I saw that @Owersun mentioned they would be look this week, and I’m not aware of any known bugs on the current platform.

经过验证的代码，且只是平台特定的，为什么不合？

如果有性能问题，macOS 谁用谁优化就行

我听他们说现在的tun晾一会会卡死来着

经过验证的代码，且只是平台特定的，为什么不合？

没人用macos 这又是个刚注册的小号 也明说了是vibe的 这如果有问题没人管啊

我听他们说现在的tun晾一会会卡死来着

那也与这个 PR 无关啊

没人用macos 这又是个刚注册的小号 也明说了是vibe的 这如果有问题没人管啊

有总比没有强，用不了的话自然会有 macOS 的 PR 修复

那也与这个 PR 无关啊

我的意思是有时间vibe这个要不试试vibe修这些

有总比没有强，用不了的话自然会有 macOS 的 PR 修复

毕竟那个一堆问题的wireguard出站也是“经过验证”（指能启动并连上）
如果现在的策略是不管这些有的没的 能跑就合那当我没说吧
这大部分是直接从win版本搬来的的 比如Capabilities() 实际情况不是这样

没人用macos 这又是个刚注册的小号 也明说了是vibe的 这如果有问题没人管啊

xray的macos用户应该比较少，而且小火箭也支持macos，开发的话socks一般够用，但如果是vibe coding那就更没兴趣用tun了

我的意思是有时间vibe这个要不试试vibe修这些

经典无和有的区别，这两件事又不冲突，我们又没有 macOS 机器，不要奢求太多，先有人 PR 能用的下一步就有人 PR 好用的

xray的macos用户应该比较少，而且小火箭也支持macos，开发的话socks一般够用，但如果是vibe coding那就更没兴趣用tun了

这代码又不多，与其说没有兴趣用不如自己把它改成鲁棒性更强的呢

这代码又不多，与其说没有兴趣用不如自己把它改成鲁棒性更强的呢

目前还没那能力，如果有大佬维护可以帮忙测试

还有 macOS 上的进程名路由你们有机器的可以试着开发一下，感觉可能和 Linux 上的差不多 @osypai @maoxikun

iOS TUN 就只能靠相关开发者了 @yiguodev @mangustyura ，可能和 macOS 的有相似之处吧，顺便改进下 macOS TUN 的代码

My machine I work on is a Mac...
I had the same suspicion as you do, - not a lot of people use it. =) Didn't really see a reason to support for it because of that.
But sure I can have a look, if people want it. Should be pretty simple, gVisor support darwin, wireguard has darwin support. Should be piece of cake to check it and implement similar. Way easier than Windows.
I'll have a look.

@Owersun 加油，macOS 进程名路由你也看一下吧，已经打算五天后再发一个版本

The usual, please give me couple of days. Maybe i’m not that effective without vibe coding, but i really like to test things for a day or two.
I’ll open a pull request with enhancements to darwin implementation.

我听他们说现在的tun晾一会会卡死来着

我在安卓测试的时候遇到一个很奇怪的问题 就是 tun 已经打开了 收到流量 但是这时 core 还没完全启动完成 启动完成之后反而无流量了

22:37:32.108  I  Stop Service
22:37:32.114  I  [Debug] app/log: Logger closing
22:37:32.122  D  setTopOnBackInvokedCallback (unwrapped): null
22:37:32.159  D  hide(ime())
22:37:32.159  I  com.v2ray.ang.fdroid:fa64657d: onCancelled at PHASE_CLIENT_ALREADY_HIDDEN
22:37:32.440  D  endAllActiveAnimators on 0xb40000735ff01370 (MenuPopupWindow$MenuDropDownListView) with handle 0xb40000734fd1d000
22:37:34.246  I  Resolved IPs for x: x
22:37:34.302  I  Core StartLoop  109
22:37:34.303  I  initializing core...
22:37:34.308  I  [Debug] app/log: Logger started
22:37:34.308  I  [Info] app/dns: DNS: created UDP client initialized for 1.1.1.1:53
22:37:34.309  I  [Debug] app/proxyman/inbound: creating stream worker on 127.0.0.1:10808
22:37:34.309  I  [Info] proxy/tun: read Android Tun Fd 109
22:37:34.310  I  [Info] proxy/tun: xray0 created
22:37:34.312  I  [Info] proxy/tun: xray0 up
22:37:34.313  I  [Info] [190601941] proxy/tun: processing from udp:10.10.14.1:60603 to udp:216.239.32.223:443
22:37:34.313  I  [Info] [2829439267] proxy/tun: processing from udp:10.10.14.1:49159 to udp:1.1.1.1:53
22:37:34.313  I  [Info] [677907560] proxy/tun: processing from udp:10.10.14.1:6025 to udp:1.1.1.1:53
22:37:34.313  I  [Warning] [2829439267] app/dispatcher: non existing outTag: dns-out
22:37:34.313  I  [Warning] [677907560] app/dispatcher: non existing outTag: dns-out
22:37:34.313  I  [Info] [3226607700] proxy/tun: processing from udp:10.10.14.1:3733 to udp:1.1.1.1:53
22:37:34.313  I  [Warning] [3226607700] app/dispatcher: non existing outTag: dns-out
22:37:34.313  I  [Info] [1329325774] proxy/tun: processing from tcp:10.10.14.1:53924 to tcp:1.1.1.1:853
22:37:34.314  I  starting core...
22:37:34.314  I  from tcp:10.10.14.1:53924 accepted tcp:1.1.1.1:853 [tun -> proxy]
22:37:34.314  I  [Info] [1329325774] app/dispatcher: taking detour [proxy] for [tcp:1.1.1.1:853]
22:37:34.314  I  [Info] [1329325774] transport/internet/tcp: dialing TCP to tcp:x:443
22:37:34.314  I  [Info] app/dns: returning 1 IP(s) for domain x -> [x]
22:37:34.314  I  [Info] [1329325774] transport/internet: replace destination with tcp:x:443
22:37:34.314  I  [Debug] [1329325774] transport/internet: dialing to tcp:x:443
22:37:34.314  I  [Info] transport/internet/tcp: listening TCP on 127.0.0.1:10808
22:37:34.314  I  [Info] transport/internet/udp: listening UDP on 127.0.0.1:10808
22:37:34.314  I  [Warning] core: Xray 26.1.18 started
22:37:34.315  I  Starting core successfully
22:37:34.515  I  [Info] [190601941] app/dispatcher: taking detour [block] for [udp:216.239.32.223:443]
22:37:34.515  I  from udp:10.10.14.1:60603 accepted udp:216.239.32.223:443 [tun -> block]
22:37:35.052  I  [Info] [1329325774] proxy/vless/outbound: tunneling request to tcp:1.1.1.1:853 via x:443
22:37:35.054  I  [Debug] [1329325774] proxy: XtlsFilterTls found tls client hello! 228
22:37:35.054  I  [Debug] [1329325774] proxy: XtlsPadding 228 974 0
22:37:35.369  I  [Debug] [1329325774] proxy: Xtls Unpadding new block, content 1448 padding 101 command 0
22:37:35.373  I  [Debug] [1329325774] proxy: XtlsFilterTls found tls 1.3! 1163 TLS_AES_128_GCM_SHA256
22:37:35.375  I  [Debug] [1329325774] proxy: Xtls Unpadding new block, content 1815 padding 174 command 0
no traffic after this

我在安卓测试的时候遇到一个很奇怪的问题 就是 tun 已经打开了 收到流量 但是这时 core 还没完全启动完成 启动完成之后反而无流量了

这个可以调试出来问题在哪的吧，别的入站有这情况吗

改了一下 测试用platform.TunFdKey 别创建新的 utun device/setMTU/setState，成功在iOS跑 🎉

speedtest时 network extension太容易炸了 估计内存不够

I did some research and, on macOS, it looks like there are basically two ways to retrieve process information: running command-line tools or using libproc. The former is straightforward and not really worth discussing. The latter requires using cgo to load libproc.dylib.
Another option is to bring in a dependency like github.com/ebitengine/purego and access the FFI in a pure Go environment.
There is also a cgo-less wrapper library, github.com/sladyn98/libproc-go, but its implementation relies too heavily on Go’s internal details.

It's taking me some time to brush that up, sorry about that, I'm still preparing slight improvements to the implementation.
They are still coming.

哪位大佬能给个 macOS 里面 tun 免回环路由配置的样例啊，能自动设置 tun device ip 和相关路由吗？

I am on the enhancement task to make MacOS variant working properly, I'll add all the changes needed so that it work on MacOS when I'm done.
It's taking me some time to make it work. MacOS has additional layer of security on top of just traffic routing that need to be taken care of.

@Owersun @osypai 大佬们能给一个macos使用xraycore的tun功能完整配置示例和使用过程吗, 一直尝试不成功

@Owersun @osypai 大佬们能给一个macos使用xraycore的tun功能完整配置示例和使用过程吗, 一直尝试不成功

Just

  "inbounds": [
    {
      "port": 0,
      "protocol": "tun",
      "settings": {
        "name": "utun12",
        "MTU": 1500
      }
    }
  ],

then start the core with sudo. You can use ifconfig -l to check whether an extra utun12 device appears.

Have you successfully tried this on any other platform?

@Owersun @osypai 大佬们能给一个macos使用xraycore的tun功能完整配置示例和使用过程吗, 一直尝试不成功

Just

  "inbounds": [
    {
      "port": 0,
      "protocol": "tun",
      "settings": {
        "name": "utun12",
        "MTU": 1500
      }
    }
  ],

then start the core with sudo. You can use ifconfig -l to check whether an extra utun12 device appears.

Have you successfully tried this on any other platform?
谢谢回复,
但就这样可以了? 创建utun接口是可以成功, 但不需要设置系统路由吗?
我手动更改了系统路由,但是无法出网,所以想确认下具体流程
折腾了很久都没用
(我用了sing-box是没问题的,倒是也不需要手动设置路由信息)

@yanue You can refer to the documentation for hev-socks5-tunnel. Not adding the relevant guidance to the README was my mistake :(

@osypai macos ，是在主进程运行 xray，还是在 network extension 运行 xray，另外，我想用 LibXrayRunXrayFromJSON 方法， 如何 start the core with sudo

@yanue You can refer to the documentation for hev-socks5-tunnel. Not adding the relevant guidance to the README was my mistake :(

还是尝试不成功, sorry, 能给一个完整的xray配置(隐藏服务器信息), 然后对系统路由设置的具体命令吗 ,谢谢🙏

utun12: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 8500
        inet 10.0.0.2 --> 10.0.0.1 netmask 0xffffffff
        nd6 options=201<PERFORMNUD,DAD>

一直报错(非tun模式是正常可用的)
2026/01/24 19:17:24.626897 [Info] [3398390973] app/proxyman/outbound: app/proxyman/outbound: failed to process outbound traffic > proxy/vless/outbound: failed to find an available destination > common/retry: [dial tcp xxx.xxx.xx.xx:443: connect: network is unreachable] > common/retry: all retry attempts failed