问题说明及解决办法
Mac 下载 桌面端 Gemini App，无法正常登陆，在网页完成OAuth验证后，未跳转，app无反应，卡住了：此时网页提示 Authorization flow complete. Please close this tab；百度一下，才知道要在代理工具（如Flclash）开启 Tun 模式/虚拟网卡，后面开了，顺利登陆了；
Gemini 桌面端下载地址：https://gemini.google/desktop/
http://localhost:61776/?state=9qq1M0GqQXCXLiFDJQRs&iss=https://accounts.google.com&code=4/0AXlqoi6m223GnQwadqHt8fGYj9qcW7CuR-MtSCFsUrSD3eHri_MKLxsv9sn2ugkxfhashA&scope=https://www.googleapis.com/auth/flexible-api
问题的本质核心
该问题的核心在于 OAuth 2.0 授权回调（Callback）过程中的网络流量路由机制与环回地址（Loopback Address）监听逻辑。
当 Gemini 桌面端启动登录流程时，它会在本地随机构建一个轻量级 HTTP 服务器，监听特定端口（如示例中的 http://localhost:61776/），并将其作为 OAuth 的回调 URI（redirect_uri）传给浏览器。
登录成功的核心逻辑链条如下：
-
浏览器完成 Google 账号验证，拿到授权码（
code）。 -
浏览器向
http://localhost:61776/...发送 GET 请求，将授权码传递给桌面端。 -
桌面端接收到该 HTTP 请求，提取
code，并在后台向 Google 服务器换取登录凭证（Token）。
若流量未能成功到达本地监听端口，整个授权链条就会在第二步断裂，导致浏览器提示“Authorization flow complete”（授权流程完成），而桌面端因未收到回调数据而持续卡死。
为什么普通代理模式下会失败？
在未开启 TUN 模式（普通系统代理/HTTP代理）时，请求阻断的原因通常包含以下两方面：
1. 本地环回流量被代理接管或拦截（Loopback Routing Issue）
普通代理软件主要接管系统 HTTP/HTTPS 协议流量或特定 Socket。当浏览器尝试访问 http://localhost:61776/... 时：
-
如果代理规则配置不当（例如开启了全局代理且未将
localhost/127.0.0.1设为直连），浏览器会将发往localhost的请求强行发往远端代理服务器。 -
远端代理服务器显然无法访问你本地电脑上的
61776端口，导致请求超时或返回 404/500，桌面端因此无法接收到凭证。
2. 混合协议与 DNS 解析污染（DNS / Split-Tunneling Misconfiguration）
在部分代理配置下，localhost 可能被强制走代理 DNS 解析或转换为外部 IP，导致浏览器与本地桌面进程之间的通信直接被割裂。
为什么开启 TUN 模式 / 虚拟网卡就能解决问题？
TUN（Network Tunnel）模式与普通的系统代理在网络层级上有根本区别：
[ 应用层流量 ]
│
(网络层拦截) ──► TUN 虚拟网卡 ──► 内置路由引擎 (Flclash / Clash)
│
┌──────────────────┴──────────────────┐
▼ ▼
目标为 localhost / 本地端口 目标为 Google 外网服务
【系统直连路由】 【代理节点转发】
│ │
▼ ▼
Gemini 桌面端 (61776) Google 服务器开启 TUN 模式后，代理工具会在操作系统内核建立一张虚拟网卡（Virtual Network Interface Card），在 L3（网络层/IP层） 捕获所有流量：
-
精准的路由表控制：TUN 模式接管了系统底层的路由表，能够精确识别出目的地为本地回环地址（
127.0.0.1/localhost）的流量，并强制其走本地网卡直连，不经过远端节点代理。 -
完整接管与恢复标准 TCP/IP 行为：TUN 模式避开了浏览器等客户端软件对系统代理设置（System Proxy Standard）的各种复杂、不规范的读取逻辑，直接在内核层确保“外网走代理、内网/本地回环走直连”，从而保证了浏览器向
http://localhost:61776/发送的回调请求能够无缝、准确地递交给 Gemini 桌面端进程。
方案评估与风险分析
| 方案 | 优势 | 劣势/潜在风险 | 置信度评级 |
|---|---|---|---|
| 开启 TUN 模式 (当前生效方案) | • 内核级接管，彻底解决各类 App 的 OAuth 回调与 Localhost 通信异常 • 无需为每个应用单独设置代理 |
• 占用额外的虚拟网卡资源 • 若代理软件异常退出，可能导致系统网络中断（需重置网卡） |
高 (逻辑链条闭环，且有实测验证) |
| 配置 Bypass/Bypass List (替代方案) | • 轻量，无需创建虚拟网卡 | • 依赖各应用是否遵循系统代理规则，部分 Electron/Native 应用不生效 | 中 |
总结
Gemini 桌面端卡死的原因在于代理工具导致浏览器无法将 OAuth 授权码送达本地端口。开启 TUN 模式后，代理软件在内核网络层纠正了路由规则，确保发往本地 localhost 的回调请求直连通过，从而完成了授权闭环。
版权属于：毒奶
联系我们：https://limbopro.com/6.html
毒奶搜索：https://limbopro.com/search.html
番号搜索：https://limbopro.com/btsearch.html
机场推荐：https://limbopro.com/865.html IEPL专线/150Gb/¥14/月起
毒奶导航：https://limbopro.com/daohang/index.html本文链接：https://limbopro.com/archives/36180.html · 镜像：https://limbopro.github.io/archives/36180.html
本文采用 CC BY-NC-SA 4.0 许可协议，转载或引用本文时请遵守许可协议，注明出处、不得用于商业用途！
