Kong: check what is configured before changing anything

Most Kong problems are a plugin attached at a scope you did not expect. Four read-only calls tell you what the gateway will actually do with a request.

Code
# what routes exist, and in what order they will match
curl -s localhost:8001/routes | jq -r '.data[] | "\(.name) \(.paths) \(.hosts)"'

# every plugin, with its scope
curl -s localhost:8001/plugins | jq -r '.data[] |
  "\(.name)  service=\(.service.id // "-")  route=\(.route.id // "-")  consumer=\(.consumer.id // "-")"'

# one route's effective plugins
curl -s localhost:8001/routes/<id>/plugins | jq -r '.data[].name'

# and the node's own view
curl -s localhost:8001/ | jq '{version, database: .configuration.database}'
Output
billing-route ["/billing"] null
api-route     ["/api"]     ["api.example.com"]

rate-limiting  service=7c9e...  route=-        consumer=-
key-auth       service=-        route=4a1b...  consumer=-
rate-limiting  service=-        route=4a1b...  consumer=e2f1...

# Two rate-limiting rows is the shape of the commonest bug: the more
# specific one wins entirely, and the service-level config is not inherited.
Advertisement

Run this yourself in the Online Java Compiler, spin up a live REST API in the API Sandbox, or practise with Java interview questions.

Published 2026-08-25