Skip to content1. 什么时候 Google Sheets 才真的需要代理
这里真正会用到的情况其实不多。你可能身处只允许通过代理进行外发流量的公司网络，或者你的脚本、插件、或本地自动化工具因为网络要求，必须通过代理访问 Google Sheets。
这篇指南只讲这些情况，不会扩展到别的内容。它不是一篇通用的代理入门，也不是教你如何隐藏流量不让 Google 看到，或者在浏览器里更改国家地区。如果你只是坐在办公桌前用 Chrome 打开表格，也许根本用不上这些设置。
如果你是来找如何在 Google Sheets 中设置代理的，首先要知道：Google Sheets 本身通常不是代理所在的位置。代理通常在浏览器、操作系统、脚本运行环境，或者 API 客户端里。这个区别很关键；换句话说，Google Sheets 代理设置 往往发生在真正发起连接的那一层，而不是表格本身。
一个错误的假设会引发一半的混乱。很多人改了浏览器设置，然后疑惑为什么本地脚本还是失败。因为层级不同，解决办法也不同。
2. 先确认你真正能控制的是哪条连接路径
先把路径说清楚。流量是来自浏览器里的 Google Sheets 网页应用，还是来自Google Sheets API，或者来自 Apps Script、插件、或读写单元格的本地应用？
浏览器界面通常遵循系统代理或浏览器代理设置。这意味着，如果 Sheets 是在 Chrome、Edge 或 Firefox 中打开，浏览器可能已经在使用 Windows、macOS，或浏览器配置文件中设置的代理。脚本则不同。脚本可以完全忽略浏览器设置。
对于基于 API 的工作流，代理行为往往取决于客户端库或运行环境本身。如果你的 Python 应用通过 Sheets API 通信，浏览器代理不会帮到你。如果你的 Apps Script 调用远程服务，路径又会不一样。
必要的话可以先在纸上画出路径：浏览器、API 客户端、插件、脚本。只要一条线就够了。然后只在那条线上设置代理，不要四处都改。
如果你需要先了解代理术语，VPN 和代理术语表是个很适合随手查看的地方。一个定义，后面可能帮你省掉二十分钟。
3. 准备好代理信息和代理凭据
在动任何设置之前，先收集完整的代理信息：主机名、端口、协议，以及任何代理凭据。听起来很基础，但大多数配置失败都源于漏掉其中一项。8080 端口不等于 3128。HTTP 也不等于 SOCKS5。
你还需要知道这个代理是如何授权的。有些代理只允许已批准的 IP 访问；有些需要用户名和密码；有些使用 token 或 PAC 文件。这个差异会影响你在哪里配置，以及如何测试。
对于Google Sheets API，这一点会影响两次。第一，API 客户端必须通过代理访问 Google。第二，与 OAuth 或服务账号相关的认证流程，也必须能沿着同一条路径顺利完成。如果代理会拦截重定向或阻止 Google 登录页面，整条链路都可能坏掉。
在修改之前，请确认以下内容：
- 代理主机名或 IP 地址
- 端口号
- 协议：HTTP、HTTPS 或 SOCKS
- 代理是匿名、IP 白名单，还是需要认证
- 如有需要，用户名和密码
- 如果代理会检查 TLS，是否需要证书或信任设置
其中三项是不能省的：主机、端口和认证方式。少一项，你就会一直追错问题。
4. 在真正与 Google Sheets 通信的环境里设置代理
现在要把代理对应到真正发起连接的那一层。对于 Google Sheets 网页应用，通常意味着浏览器或系统代理。对于脚本或集成，通常意味着运行时中的应用级设置。
如果你是在受管电脑上的浏览器里使用 Sheets，先检查操作系统代理设置。公司镜像通常会自动把系统代理推送到 Chrome 或 Edge。那种情况下，你可能不需要手动输入任何内容，但你必须知道这台机器是否已经处在某个代理之后。
如果连接来自本地工具，设置就应该放在那个工具里。Python 客户端、Node 应用或桌面集成都应该直接把外发流量指向代理。不要指望浏览器中的 Google Sheets 会把代理设置“带”到另一个进程里。不会的。
这就是如何在 Google Sheets 中设置代理的核心判断：选择真正发起请求的那一层。一层就够了，不是全部都要。浏览器设置只影响浏览器，代码设置只影响代码。把这个边界分清，后面就简单很多；这也是 Sheets 代理配置 最容易出错、也最值得先检查的地方。
举个实际例子会更清楚。如果你能在浏览器里正常打开 Sheets，但自动化任务失败了，那说明浏览器路径没问题，脚本路径有问题。即使两者用的是同一个代理主机，也仍然是不同的修复方式。
5. 配置 Google Sheets API 请求通过代理发送
API 客户端通常会在客户端配置里，或者通过环境变量接收代理设置。具体位置取决于语言和库，但思路是一样的：发往Google Sheets API 的请求必须先通过代理，再到 Google。换句话说，Google Sheets API 代理 应该配置在发起请求的客户端里，而不是浏览器里。
如果你的应用使用带有内置传输对象的库，就去找那里是否有代理字段。如果它使用操作系统网络栈，运行时可能会自动读取系统代理。无论哪种方式，都要测试具体客户端，而不是浏览器。
OAuth 需要特别小心。代理可能会干扰登录重定向、令牌刷新调用，或者服务账号的 token 交换，前提是它阻止了 Google 端点或改写了证书。这也是为什么“能正常浏览网页”的代理，并不一定就能用于 API 流量。
要注意认证流程本身：先是客户端连接代理，然后代理放行 Google 端点，最后 API 请求成功。只要漏掉任一步，报错看起来都可能像权限问题，但实际上是网络问题。
如果你的工作流还会碰到浏览器自动化或附近页面抓取，如何选择 VPN这篇指南可以帮助你区分隐私工具和网络访问工具。它们解决的是不同的问题。
6. 安全地处理代理凭据
千万不要把代理凭据贴到共享笔记里。也不要把它们以 URL 形式直接写进源代码。这两种做法都会把一个简单的网络设置，迅速变成安全问题。
尽量使用最安全、又适合当前工具的存储方式。环境变量通常比硬编码值更好。如果平台支持，密钥管理器会更好。若团队使用部署系统，就把用户名和密码存在那里，而不是写进表格脚本本身。
如果是需要认证的代理，先确认客户端是要求把凭据单独填写，还是写进代理 URL 里。有些工具两种都支持，但并不是所有解析器都能正确处理特殊字符。密码里带 @ 或 : 时，很容易把格式弄坏。这并不罕见。
日志脱敏也很重要。如果日志里显示了完整的代理用户名或密码，就先停下来修正日志，再继续测试。安全的配置往往很无聊。很好，无聊才是目标。
如果你的代理是经过认证的 SOCKS5 代理，先确认客户端是否支持，因为并不是所有与 Sheets 相关的库都能以同样方式处理这种格式。关于这种模式，可以参考经过认证的 SOCKS5 代理文章里的更深入说明。
7. 测试 Sheets 和 Google Sheets API 是否都正常
分两步测试。第一步，在浏览器里打开 Google Sheets，确认文件能加载、菜单有响应、登录状态保持正常。第二步，从目标客户端执行一次很小的 API 读写操作。
一个合格的浏览器测试很简单：打开一个表格，刷新一次，如果策略允许，再做一次小编辑。如果页面能打开但保存失败，说明代理路径可能只通了一部分。如果页面根本打不开，浏览器或系统代理可能就错了。
一个合格的 API 测试应该只做一件小事：读取一个单元格范围，或者向测试表写入一个已知值。不要一上来就跑大批量任务。一个单元格就足以证明路径通不通。
代理路由成功时，通常会在两条路径上都表现出稳定一致的响应。失败时则会呈现规律。DNS 错误指向一个方向，凭据错误指向另一个方向。当代理检查 TLS、而客户端不信任代理的证书链时，往往会出现证书错误。
如果你想在 Sheets 之外单独检查隐私路由，可以看看如何验证你的 IP 是否。当你怀疑网络在“撒谎”时，这会是个很有用的排查手段。
8. 不要改错层，按常见故障点排查
最常见的错误，是改了浏览器代理，却以为脚本也会跟着变。不会。第二常见的错误，是改了 API 客户端，但浏览器仍在使用过期的系统代理。两个层级，两次检查。
错误的代理凭据通常会很快暴露出来：407 错误、反复要求登录，或者客户端能连上却始终无法完成认证。如果代理需要用户名和密码，请仔细核对，并留意密码里的特殊字符。多一个空格，就可能让整个测试失败。
OAuth 问题的表现不一样。如果重定向失败，可能是代理拦截了 Google 登录页面，或者把 URL 改写成了认证流程无法接受的样子。这对基于用户的 OAuth 和服务账号流程都很重要，因为 token 交换仍然依赖于顺利访问 Google。
TLS 检查还可能制造另一种麻烦。浏览器可能会容忍已安装的受管证书，但脚本或 API 客户端可能会拒绝代理的证书链。在这种情况下，代理对网页来说“正常”，但对Google Sheets API 却不行。这类分层不一致，最容易浪费整个下午。
按这个顺序回头检查设置：1）连接层，2）代理主机和端口，3）认证方式，4）证书信任路径，5）任何 OAuth 重定向或 token 交换步骤。这个顺序能先抓住最简单的故障。
如果你在测试后还需要更完整的代理背景资料，可以继续看代理认证最佳实践指南。它会把重点放在凭据上，而不是猜测上。
最后再强调一次：如果 Sheets 在浏览器里能用，但 API 客户端还是失败，就不要继续改浏览器设置了。层级错了，去修客户端。