libproxy 选择路由，连接由你的客户端建立
把 libproxy 的结果当作按 URL 分发的路由候选，而不是指望发现过程会重定向应用的套接字。
如果 libproxy 返回了代理 URI，而下一个套接字却直接连接，请检查交接环节。libproxy 只负责发现策略；它不会拦截应用打开的每一个套接字。
- 查询资源。 在文档所述的 libproxy 0.5 C API 中，创建代理工厂并询问实际的目标 URL。
- 解读有序候选。 HTTP、SOCKS 与直连结果需要不同处理。保留它们的优先顺序和既定的失败策略。
- 配置使用方。 把选定的代理类型、端点与认证安排交给支持它们的传输层。原始 TCP 套接字不会从返回的 URI 中获得 CONNECT 或 SOCKS 协商。
不要把某一个答案保存成所有目标的固定路由，也不要因为第一个代理失败过一次就让直连路由永久生效。
如果 HTTP 客户端已经集成了系统代理或 PAC 发现，请只选定一个选择方。两个独立的选择器再加一层包装，可能产生两种策略都没设想过的路由。
在原生代码中，遵循已安装 API 的工厂与结果内存生命周期。复用工厂可以保留有用的发现状态，但每个目标仍然需要一次查询。请把选择记录与连接结果分开记录：返回的 URI 并不证明认证、域名解析或后续访问已经成功。