dae, means goose, is a high-performance transparent proxy solution.
To enhance traffic split performance as much as possible, dae employs the transparent proxy and traffic split suite within the Linux kernel using eBPF. As a result, dae can enable direct traffic to bypass the proxy application's forwarding, facilitating genuine direct traffic passage. Through this remarkable feat, there is minimal performance loss and negligible additional resource consumption for direct traffic.
As a successor of v2rayA, dae abandoned v2ray-core to meet the needs of users more freely.
- Implement
Real Directtraffic split (need ipforward on) to achieve high performance. - Support to split traffic by process name in local host.
- Support to split traffic by MAC address in LAN.
- Support to split traffic with invert match rules.
- Support to automatically switch nodes according to policy. That is to say, support to automatically test independent TCP/UDP/IPv4/IPv6 latencies, and then use the best nodes for corresponding traffic according to user-defined policy.
- Support advanced DNS resolution process.
- Support full-cone NAT for shadowsocks, trojan(-go) and socks5 (no test).
- Support various trending proxy protocols, seen in proxy-protocols.md.
Please refer to Quick Start Guide to start using dae right away!
- If you setup dae and also a shadowsocks server (or any UDP servers) on the same machine in public network, such as a VPS, don't forget to add
l4proto(udp) && sport(your server ports) -> must_directrule for your UDP server port. Because states of UDP are hard to maintain, all outgoing UDP packets will potentially be proxied (depends on your routing), including traffic to your client. This behaviour is not what we want to see.must_directmakes all traffic from this port including DNS traffic direct. - If users in mainland China find that the first screen time is very long when they visit some domestic websites for the first time, please check whether you use foreign DNS to handle some domestic domain in DNS routing. Sometimes this is hard to spot. For example,
ocsp.digicert.cnis included ingeosite:geolocation-!cnunexpectedly, which will cause some tls handshakes to take a long time. Be careful to use such domain sets in DNS routing.
See How it works.
- Automatically check dns upstream and source loop (whether upstream is also a client of us) and remind the user to add sip rule.
- MACv2 extension extraction.
- Log to userspace.
- Protocol-oriented node features detecting (or filter), such as full-cone (especially VMess and VLESS).
- Add quick-start guide
- ...
Special thanks goes to all contributors. If you would like to contribute, please see the instructions. Also, it is recommended following the commit-msg-guide.
