在Kong网关的日常运维中，路由不通是最常见的故障之一。很多时候明明改了配置、重启了网关，用户还是访问不了对应的服务，排查半天找不到根因——这时候用上Deck工具，就能帮你快速定位问题，不用在Kong的网页后台一个个翻配置。

一、Kong路由不通的常见场景

1.1 服务上游地址或端口写错

很多人改配置的时候，手滑把服务的地址写错了，比如把user-service写成了userservice，或者把端口80写成了808，Kong根本找不到对应的服务，自然路由不通。比如你要连的服务是运行在192.168.1.100的8080端口，结果配置里写成了192.168.1.101的8081，肯定访问不了。

1.2 路由规则冲突

Kong里的路由是匹配路径、域名这些规则的，如果有两个路由的匹配条件重复，比如一个路由匹配路径/api，另一个也匹配/api，而且优先级设置不对，就会出现请求被错误路由拦截，甚至根本找不到对应服务的情况。

1.3 插件配置拦截问题

很多时候加了身份验证、限流这些插件，插件的配置错了，比如把身份验证的密钥写错了，或者插件绑定的服务不对，也会导致请求被拦截，看起来像路由不通，实际是插件在搞鬼。

二、Deck工具的核心作用

Deck是Kong官方推出的命令行工具，相当于给Kong的配置做“全方位体检”的工具。它不用你手动在Kong的后台UI里点来点去，而是直接和Kong的管理API交互，既能导出所有配置当备份，也能批量校验配置有没有语法错误、依赖的资源（比如上游服务）是否存在，甚至能对比本地配置和在线配置的差异，比一个个手动查快太多，尤其适合配置多的大型项目。

三、用Deck快速校验并定位根因的完整步骤

这里用实际操作的例子，假设你已经装了Kong网关，现在遇到路由不通的问题，一步步来：

3.1 环境准备：安装Deck工具

首先要在本地或能访问Kong Admin的机器上装Deck，不同系统的安装命令不一样，这里以macOS为例，其他系统可以换对应版本，代码如下：

# 下载macOS arm64架构的Deck二进制包，替换系统架构的话改对应的链接
curl -sL https://github.com/Kong/deck/releases/download/v1.35.0/deck_1.35.0_darwin_arm64.tar.gz | tar -xzf - -C /usr/local/bin
# 验证是否安装成功，输出版本号就是成功
deck version

3.2 导出当前Kong的配置文件

先把Kong里的所有配置导出成本地的YAML文件，这样不用在Kong后台改，在本地就能调整，注释清楚：

# 配置Kong Admin的地址，根据你的实际情况改，这里是本地的Kong
export KONG_ADMIN_URL=http://localhost:8001
# 如果你的Kong Admin开了认证（比如配置了API Key），就加下面这行，把your_token换成实际的token
# export KONG_ADMIN_TOKEN=your_admin_token
# 导出所有配置到kong.yaml文件，这个文件包含所有服务、路由、插件的信息
deck dump --output kong.yaml

3.3 模拟配置错误的场景（故意写错服务地址）

现在我们故意把配置里的上游服务地址写错，模拟真实的错误场景，修改刚导出的kong.yaml里的服务配置，比如把test-service的host改成不存在的wrong-service.com，修改后的yaml片段：

services:
- path: /
  port: 80
  protocol: http
  host: wrong-service.com # 故意写错的服务地址，模拟问题来源
  name: test-service # 服务名称，Kong里唯一标识
  routes:
  - name: test-route
    paths:
    - /test # 路由匹配的路径，访问/test就到这个服务

3.4 用Deck校验配置，定位根因

Deck的validate命令会检查配置的合法性和依赖资源，比如上游服务是否存在，语法对不对，执行这个命令：

# 用校验命令检查修改后的配置，输出具体的错误信息
deck validate --kong-url http://localhost:8001 --config kong.yaml

这时候会输出明确的错误：error: service "test-service" cannot resolve hostname "wrong-service.com"——一下子就找到了根因：服务地址写错了，导致Kong解析不到这个服务，所以路由不通，不用再一个个翻配置了。

3.5 修复配置后重新校验和同步

找到问题后，把host改回正确的地址（比如192.168.1.100），再执行一次validate，没有错误后，把本地配置同步到Kong里，让配置生效：

# 同步本地的配置到Kong网关，自动更新配置，不用手动改后台
deck sync --config kong.yaml

四、Deck工具排查的优缺点

4.1 优点

  1. 批量处理快：比在Kong后台一个个查配置效率高，适合配置多的大项目；
  2. 可备份可对比：导出的配置文件可以做版本控制，还能和之前的配置对比，知道改了哪里导致问题；
  3. 校验全面：能检查语法错误、依赖资源是否存在，不会漏问题；
  4. 适合自动化：可以集成到CI/CD流程里，每次改配置就校验，避免线上问题。

4.2 缺点

  1. 依赖Admin API：如果Kong的Admin API出问题（比如端口被封、认证失败），Deck就用不了；
  2. 不能实时看请求：只能检查配置本身，没法看具体的请求日志，有时候需要结合Kong的日志排查；
  3. 版本兼容：不同版本的Deck和Kong可能不兼容，要选对应版本的Deck，不然会出现配置解析错误。

五、排查时的注意事项

  1. 先确认Kong Admin健康：用curl http://localhost:8001检查是否能访问，不然Deck连不上Kong；
  2. 导出配置前要停掉所有动态配置：如果有人在Kong后台改了配置，没等同步到Deck的导出，导出的配置可能和在线不一致，最好让所有配置操作通过Deck来做；
  3. 校验前要对应版本：Deck的版本要和Kong的版本匹配，比如Kong 3.x要用对应3.x的Deck，不然会出现配置解析错误；
  4. 不要硬编码认证信息：用环境变量存KONG_ADMIN_TOKEN，不要直接写在配置文件里，避免泄露。

六、总结

遇到Kong路由不通的问题，不要急着重启网关，先试试Deck工具：先导出配置，再校验，就能快速找到配置里的错误，比手动排查高效太多。它不仅能解决路由不通的问题，还能帮你管理整个Kong的配置，适合日常运维和开发调试。只要注意它的依赖和版本问题，就能发挥最大的作用。