mihomo: [Bug] can clash.meta transfer IPv6 traffic?
Verify steps
- 确保你使用的是本仓库最新的的 clash 或 clash Alpha 版本 Ensure you are using the latest version of Clash or Clash Premium from this repository.
- 如果你可以自己 debug 并解决的话,提交 PR 吧 Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.
- 我已经在 Issue Tracker 中找过我要提出的问题 I have searched on the issue tracker for a related issue.
- 我已经使用 Alpha 分支版本测试过,问题依旧存在 I have tested using the dev branch, and the issue still exists.
- 我已经仔细看过 Documentation 并无法自行解决问题 I have read the documentation and was unable to solve the issue.
- 这是 Clash 核心的问题,并非我所使用的 Clash 衍生版本(如 OpenClash、KoolClash 等)的特定问题 This is an issue of the Clash core per se, not to the derivatives of Clash, like OpenClash or KoolClash.
Clash version
Clash Meta v1.16.0
What OS are you seeing the problem on?
Linux
Clash config
port: 8080
socks-port: 1080
mode: rule
log-level: debug
ipv6: true
dns:
enable: true
listen: 0.0.0.0:53
ipv6: true
tun:
enable: true
stack: system
dns-hijack:
- any:53
auto-route: true
auto-detect-interface: true
Clash log
No response
Description
does clash.meta have ability to pass ipv6 traffic? my proxy server is dual-stack. inside it, i can ping6 an ipv6 or ssh to a ipv6 address. but, at client side, network is only ipv4.
I thought if i activate a proxy to that server in TUN mode , i’d be able to ping6 at client side but this doesn’t work:
$ ping 2001:4860:4860::8888
connect: Network is unreachable
no trace about this query is shown on the logs.
i do netstat -lntup
, no tcp6 or udp6 connections are listening on 1080 or 8080.
However, nslookup ipv6.google.com
works and i see a line in logs related to it.
In short, i want to ping6 or ssh -6
at an ipv4-only client side using the dual-stack proxy server.
About this issue
- Original URL
- State: closed
- Created 9 months ago
- Comments: 28
The machine on which you deployed the TUN does not support access to an IPv6 network, so there is no IPv6 default route, and Clash Meta has not configured an IPv6 address and route for the TUN device, so it rejected your connection at the routing decision stage
That’s why you’ll get an error if you try to access the IPv6 address directly. The routing decision takes precedence over iptables, and the connection will be rejected before it is processed by iptables!
Fake IP only provides A record resolution, so it works, but you’ll still fail when accessing IPv6 addresses directly
You can configure a default route yourself so that the kernel doesn’t reject your connection during the routing decision phase eg.
面板增加了个检测代理是否支持 ipv6 的功能
https://github.com/MetaCubeX/metacubexd/pull/403
Sorry, my test is normal