你的观察完全是标准、预期的行为 #

首先可以明确：你的发现非常准确，这是SOCKS5代理和系统级网络配置的普遍局限。绝大多数操作系统（包括macOS、Windows、Linux）以及普通第三方应用，确实只会将系统级SOCKS代理设置应用于TCP流量，而默认忽略绝大多数UDP流量，直接让UDP包发往最终目标地址。

背后的核心原因有两点：

1. SOCKS5 UDP的协议依赖：SOCKS5的UDP转发需要客户端先通过UDP ASSOCIATE命令与代理建立专属关联通道，之后所有UDP包必须先发送到代理，再由代理转发到目标。但这个逻辑需要应用主动实现适配，而很多系统组件（比如DNS解析服务、系统级网络工具）和第三方应用根本没有做这个开发，直接使用原始UDP套接字发送流量。
2. 系统代理的设计定位：系统级SOCKS代理本质是给应用层TCP客户端提供的配置，而非底层IP层的路由规则。除非操作系统明确开启了“强制UDP走代理”的特定选项（比如macOS的专属复选框），否则系统不会自动将UDP流量路由到SOCKS代理；即使开启了该选项，仍有大量应用会绕过配置，因为它们的UDP实现不依赖系统代理框架。

结合你的Wireshark测试结果：UDP包直接发往8.8.8.8等地址，正是因为macOS默认没有将UDP流量导向你的SOCKS5代理，应用也没有主动走SOCKS5的UDP通道。

要实现全流量透明代理，Android VpnService确实是必要选项 #

如果你的目标是让所有应用的UDP流量都强制走你的SOCKS5代理（无论应用是否支持SOCKS5协议），那么Android的VpnService是唯一可行的无root方案，原因如下：

• 纯SOCKS5代理的固有局限：纯SOCKS5是应用层代理，完全依赖应用主动遵守代理配置并实现SOCKS5的UDP关联逻辑。对于不支持的应用或系统组件，你没有任何手段强制它们走代理。
• VpnService的工作机制：VpnService会在Android系统中创建一个虚拟网络接口（TUN设备），系统会自动将所有TCP和UDP流量路由到这个虚拟接口。你的应用可以捕获所有经过该接口的IP数据包，之后自行处理：既可以将其封装为SOCKS5协议包转发到远端，也可以在本地完成SOCKS5代理的核心逻辑，甚至直接转发到目标地址。

这种方式是完全“透明”的——所有应用（包括系统组件）都感知不到代理的存在，所有流量都会被你的应用捕获和处理，从根源上解决UDP绕路的问题。

纯SOCKS5场景的临时调试建议 #

如果你暂时不想切换到VpnService，可以先尝试以下操作验证UDP是否能走代理：

• 开启macOS的UDP代理开关：在Mac的「系统设置-网络-高级-代理」中，找到你的SOCKS5代理配置，勾选「通过代理发送所有UDP流量」选项，之后再用Wireshark测试UDP流量是否会路由到你的Android服务器。
• 应用级代理配置：对于支持的应用（比如Chrome浏览器），可以在应用内手动开启SOCKS5代理并启用UDP支持（比如Chrome使用--proxy-server=socks5://ip:port启动，会自动处理UDP/QUIC流量的代理）。

但要注意，即使完成这些配置，仍然无法覆盖所有应用和系统组件，这是纯应用层SOCKS5代理的天然局限。

总结 #

你的观察是完全正常的系统行为，系统级SOCKS代理默认仅处理TCP流量；如果要实现全流量（TCP+UDP）的透明代理，Android的VpnService是必不可少的解决方案。