Configuration Detector

Xray-core 现支持 FullCone 和 Symmetric 两种模式，而 VLESS、VMess、Mux 暂不支持 FullCone，需要 Symmetric 模式

所以为了防止 VLESS、VMess、Mux 被应用 FullCone，v1.2.0 开始有一个配置检测机制，说明如下：

1. v1.2.1 开始此机制被移至 core/xray.go 的 initInstanceWithConfig 函数开头，以便在 v2rayNG 上生效 https://github.com/XTLS/Xray-core/issues/138#issuecomment-757437547
2. Xray-core 默认选择 FullCone 模式，除非出站配置有 VLESS/VMess 且无 SS/Trojan，此时是 Symmetric
3. 若出站配置的任一 SS/Trojan 开了 Mux，则一票否决，Xray-core 选择 Symmetric 模式

Optimizations & Fixes

TPROXY

修复 TPROXY 的 UDP/IPv6 伪造，详见 https://github.com/XTLS/Xray-core/issues/137#issuecomment-756064627 ，十分感谢 @Ninedyz @changyp6 发现、定位问题

关于 TPROXY UDP 的重要说明：

其它软件 TPROXY FullCone 的实现方式是为每一个返回的 UDP 包创建一个 connected UDP socket，write 一次即销毁 而 Xray-core 的实现方式是创建 unconnected UDP socket，且 writeTo 后不销毁，存进 map 供下次复用 这样做更优雅，理论上也有更好的性能，要求 iptables 没有针对 UDP 的“避免已有连接的包二次通过 TPROXY”规则

（实际上对于其它软件 TPROXY FullCone 的实现方式，这个 UDP 规则似乎也没有用，因为都会进 TPROXY）

UDP Worker

调整入站 UDP Worker 的 GC 策略为“每 60 秒清理一次 300 秒无活动的映射”，影响 Socks、SS、TPROXY，详见 https://github.com/XTLS/Xray-core/issues/129#issuecomment-757355137

之前没有注意到这个机制，调整后 UDP 的整体表现更加稳定了，彩虹六号再也不会掉线了，十分感谢 @GleenJi 等协助测试

Log

根据这个提议 https://github.com/XTLS/Xray-core/discussions/56#discussioncomment-255112 增强 access 日志信息 @eMeab https://github.com/XTLS/Xray-core/pull/121

现在你可以在 access 日志中看到路由信息了，格式为 [inbound tag -> outbound tag]，注意目前需经过路由才有完整信息

Socks

优化 Socks 代码、智能化 Socks5 的 UDP Associate 回应：

现在 Socks 入站开启 UDP 时无需再额外填本机 IP 了，且可以接受来自任何网口的请求（若配置中额外填了本机 IP，则以它为准）

Trojan

精简 Trojan UDP 的处理代码 @maskedeken https://github.com/XTLS/Xray-core/pull/142

修复 Trojan 出站 TCP 行为：一些 TCP 连接是服务端先发数据，现在 Trojan 可以在此场景下正常工作了，详见 https://github.com/XTLS/Xray-core/issues/127#issuecomment-756720453

Chores

• Upgrade dependencies
• Update geoip.dat, geosite.dat

Notices

1. Socks5、Shadowsocks 都是原生 UDP，它们的 UDP 不走底层传输方式
2. VLESS、Trojan、VMess、Mux 都是 UDP over TCP，且走底层传输方式
3. HTTP 出入站不支持代理 UDP，Socks 版本 5 之前也不支持 UDP
4. 这里的 FullCone 指的是 UDP 的 NAT 行为，配置时尤其注意防火墙
5. 链式代理若要实现 FullCone，一般来说所有环节都要支持 FullCone
6. Docker 若要实现 FullCone，相关容器的网络模式需要是 Host