通过代理追踪 OmniAuth 登录
跟随浏览器重定向和 Rails 侧的令牌交换，只在需要代理的请求上配置代理。
用户点击“登录”，进入提供方页面，然后返回 Rails。下一步仍然可能失败，因为它会从 Rails 服务器发起一条新的连接。
browser → provider authorization page → browser callback to Rails
Rails → provider token endpoint → Rails浏览器按照自身的网络配置完成授权重定向；Rails 则使用已安装的 OmniAuth 策略所选的 HTTP 客户端执行后通道令牌交换。运行在公司代理后面的工作进程，需要在这类发往提供方的请求上走那条路由。
OAuth 1.0 在用户授权之前还有一个服务器端的请求令牌步骤；OAuth 2.0 的授权码流程在回调之后有自己的令牌交换。具体顺序取决于所用策略，但浏览器和应用服务器始终是两个不同的起点。
定位客户端的配置
沿着策略找到发送令牌和提供方 API 请求的 HTTP 客户端，使用该客户端有文档记录的代理选项。有些策略把客户端选项传给某个 OAuth 库，另一些则在它下面配置 HTTP 连接。某个策略接受的选项，并不会自动变成 OmniAuth 的共享选项。
让提供方的授权、令牌和回调 URL 继续描述它们实际对应的服务。出站代理是用于访问提供方的传输设置，既不是回调地址的替代品，也不是要加进 OAuth 请求参数的字段。
排查登录时，标出最后完成的那一步。提供方登录页已经渲染，说明浏览器的路径是通的；Rails 收到了回调，说明浏览器回来了；随后的令牌请求，才是检查 Rails 进程是否遇到代理连接、质询或提供方响应的位置。