Hasura GraphQL控制台执行查询报504 Gateway Time-out错误

这个问题本质是你以为两边发的是完全相同的请求，但实际从请求链路、参数到执行环境都存在差异，常见触发点如下：

• 控制台请求走专属代理，超时阈值更短：绝大多数自托管Hasura场景下，控制台的API请求会走/console路径下的内置代理，和前端React直接调用的/v1/graphql端点不是同一条网关路由，运维通常只会给业务用的/v1/graphql配更长的超时，控制台代理默认超时经常是30s，刚好卡阈值触发504。
• 两边实际执行的查询并不一致：你肉眼看查询结构一样，但控制台用admin身份登录时，不会触发任何行级权限过滤，也不会自动带业务角色默认配置的返回条数限制；而React端调用用的是业务角色（比如user、anonymous），权限规则会自动追加过滤条件、默认limit，实际扫描的数据量比admin角色小几个量级。另外Hasura控制台的GraphiQL工具会周期性发schema内省请求，这些额外请求会挤占数据库连接池资源，你的业务查询排队等连接的时间算进总耗时就容易超时，React端不会发这类冗余内省请求。
• 缓存策略差异：控制台发的请求默认带Cache-Control: no-cache头，每次都直接打数据库做冷查询；而React端的请求会经过网关CDN、Hasura查询缓存，多数时候直接命中缓存返回，自然更快。
• 超时配置差异：Hasura控制台前端自身的请求超时默认设为30s，到点直接断开连接触发网关超时；而React端你自己封装的fetch/axios大概率配了更长的超时时间，甚至带失败重试，能等到慢查询返回。

• 先抓包对比真实请求：打开浏览器F12网络面板，分别截获控制台和React端触发的GraphQL请求，逐一对比三个维度：一是请求路径，确认是不是走了不同的网关路由；二是请求头，重点看x-hasura-role、缓存控制头有没有差异；三是请求体，把query和variables完全复制出来逐字对比，确认有没有控制台自动追加的__typename字段、隐式limit、多余嵌套字段，同时排查有没有混杂内省请求占资源。
• 查数据库侧慢日志：把Postgres慢查询阈值设为1s开启日志，分别触发两边的请求，看实际落到库的生成SQL是不是完全一致，看执行计划的扫描行数、索引命中情况：如果是_ilike '%xxx%'这种两侧带通配符的模糊查询，普通B树索引完全不生效，230万条数据全表扫本身就要20-40秒，要是前端查询因为权限规则多带了用户ID、租户ID这类过滤条件，扫描行数降到几百几千，自然秒回。
• 查网关和连接池配置：看反向代理（Nginx、K8s Ingress、API网关）上不同路径的超时配置，再看Hasura连接池的活跃连接数，触发控制台查询的时候是不是连接被占满，请求在排队等连接。

• 先解决慢查询根源：邮箱检索不要用两侧通配的_ilike '%keyword%'，如果是前缀匹配就改_ilike 'keyword%'，给邮箱字段建不区分大小写的B树索引：CREATE INDEX idx_users_email_lower ON users USING btree (lower(email));；如果确实需要全模糊匹配，开启Postgres的pg_trgm扩展，给邮箱字段建GIN索引支持模糊查询走索引，避免全表扫。
• 对齐两边请求配置：在控制台测试时手动在请求头里加上和React端完全一致的x-hasura-role等业务头，查询语句里手动加上和前端一致的limit参数，不要直接用admin角色无限制查全表。
• 调整链路配置：把控制台代理路径的超时时间和/v1/graphql路径对齐，至少设为60s以上；也可以直接在Hasura控制台设置里关闭“服务器代理请求”选项，让控制台直接请求GraphQL端点，不走专属代理。
• 优化资源配置：根据数据库规格调大Hasura连接池上限，关闭GraphiQL的自动schema刷新功能，避免内省请求挤占连接；高频查询可以开Hasura自带的查询缓存，减少打库次数。

内容的提问来源于stack exchange，提问作者Mohamed Afzal