dae

dae, means goose, is a high-performance transparent proxy solution.

In order to improve the traffic split performance as much as possible, dae runs the transparent proxy and traffic split suite in the linux kernel by eBPF. Therefore, dae has the opportunity to make the direct traffic bypass the forwarding by proxy application and achieve true direct traffic through. Under such a magic trick, there is almost no performance loss and additional resource consumption for direct traffic.

As a successor of v2rayA, dae abandoned v2ray-core to meet the needs of users more freely.

Features

1. Implement Real Direct traffic split (need ipforward on) to achieve high performance.
2. Support to split traffic by process name in local host.
3. Support to split traffic by MAC address in LAN.
4. Support to split traffic with invert match rules.
5. 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.
6. Support advanced DNS resolution process.
7. Support full-cone NAT for shadowsocks, trojan(-go) and socks5 (no test).

Getting Started

Please refer to Quick Start Guide to start using dae right away!

Documentation: https://dae.v2raya.org

Notes

1. 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_direct rule 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_direct makes all traffic from this port including DNS traffic direct.
2. 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.cn is included in geosite:geolocation-!cn unexpectedly, which will cause some tls handshakes to take a long time. Be careful to use such domain sets in DNS routing.

How it works

See How it works.

TODO

• 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
• ...

Contributors

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.

License

AGPL-3.0 (C) daeuniverse

Stargazers over time