同一个后端，用 REST 接口时走代理IP 一直很稳，换成 GraphQL 就时不时超时、偶发报错。是代理IP 的问题，还是接口本身的问题？多数时候两者都有份——GraphQL 的请求形态和传统接口差别不小，一些在普通接口上不成问题的做法，到了这里会被放大。
为什么 GraphQL 的请求更容易撞上限流
传统接口按路径区分功能，查用户、查订单、查列表各走各的地址，限流往往也按地址分别计数。GraphQL 只有一个端点，所有查询都打到同一条路径上，限流这一层看到的不再是”某个接口被调了几次”，而是”这一个端点被打了多少次”。配额消耗速度自然快得多；走代理IP 时如果多个任务共用同一个出口，计数还会叠加在一起，更容易先触顶。
为什么 POST 请求在代理IP 下的表现不一样
GraphQL 的查询通常放在请求体里用 POST 发出，而不是像传统接口那样把参数挂在地址后面。这个差别带来两个后果：一是中间环节的缓存大多只认地址，POST 请求基本享受不到缓存，每次都实打实打到后端；二是 POST 默认不被自动重试，一旦超时就直接失败，不像幂等的 GET 那样可以悄悄补一次。走代理IP 时链路多了一段，超时的概率本就略高，不会重试这一点就被放大了。
超时了，怎么判断是查询太重还是链路问题
先看响应体积。查询嵌套得深、字段取得多，返回体会明显偏大，传输时间跟着涨。再看查询本身：同样的查询在直连环境下跑一遍，直连也慢就说明问题在查询；直连很快、走代理IP 才慢，就要往链路上查。最后看错误类型——连接超时偏向链路，服务端返回错误偏向查询或后端。
常见做法是一超时就换出口，换个出口能通就认定是代理IP 的毛病。这个判断漏了一环：换出口也可能只是换到了当时负载较轻的后端实例，症结仍在查询本身，等下一次高峰照样复现。
更稳妥的做法是先精简查询。把字段收敛到真正需要的范围，把大列表分页，把能合并的请求合并，往往比换出口有效得多。查询瘦下来之后，链路上那点差异通常就不那么显眼了。
还需要留意查询复杂度限制。部分服务端会对查询的深度、字段总数设上限，超限直接拒绝并返回错误。这类失败和链路毫无关系，特征也很明显：请求很快就返回，而不是一直等到超时。遇到”秒失败”先往这边查，比换出口快得多。
需要注意的是，批量查询与订阅这两类用法对长连接的依赖更强，出口变动带来的影响也更大，规划时把连续性放在频率前面考虑。
做数据同步任务时最常见的场景是：白天跑得好好的，晚上任务一密集就开始零星超时。这时候先把单次查询的字段数压一压、把并发降一降，比反复切换代理IP 出口更能解决问题。