Skip to content
Kong Docs are moving soon! Our docs are migrating to a new home. You'll be automatically redirected to the new site in the future. In the meantime, view this page on the new site!
Kong Logo | Kong Docs Logo
  • Docs
    • Explore the API Specs
      View all API Specs View all API Specs View all API Specs arrow image
    • Documentation
      API Specs
      Kong Gateway
      Lightweight, fast, and flexible cloud-native API gateway
      Kong Konnect
      Single platform for SaaS end-to-end connectivity
      Kong AI Gateway
      Multi-LLM AI Gateway for GenAI infrastructure
      Kong Mesh
      Enterprise service mesh based on Kuma and Envoy
      decK
      Helps manage Kong’s configuration in a declarative fashion
      Kong Ingress Controller
      Works inside a Kubernetes cluster and configures Kong to proxy traffic
      Kong Gateway Operator
      Manage your Kong deployments on Kubernetes using YAML Manifests
      Insomnia
      Collaborative API development platform
  • Plugin Hub
    • Explore the Plugin Hub
      View all plugins View all plugins View all plugins arrow image
    • Functionality View all View all arrow image
      View all plugins
      AI's icon
      AI
      Govern, secure, and control AI traffic with multi-LLM AI Gateway plugins
      Authentication's icon
      Authentication
      Protect your services with an authentication layer
      Security's icon
      Security
      Protect your services with additional security layer
      Traffic Control's icon
      Traffic Control
      Manage, throttle and restrict inbound and outbound API traffic
      Serverless's icon
      Serverless
      Invoke serverless functions in combination with other plugins
      Analytics & Monitoring's icon
      Analytics & Monitoring
      Visualize, inspect and monitor APIs and microservices traffic
      Transformations's icon
      Transformations
      Transform request and responses on the fly on Kong
      Logging's icon
      Logging
      Log request and response data using the best transport for your infrastructure
  • Support
  • Community
  • Kong Academy
Get a Demo Start Free Trial
Kong Gateway
2.8.x LTS
  • Home icon
  • Kong Gateway
  • Plan And Deploy
  • DNS Considerations for Kong Gateway
github-edit-pageEdit this page
report-issueReport an issue
  • Kong Gateway
  • Kong Konnect
  • Kong Mesh
  • Kong AI Gateway
  • Plugin Hub
  • decK
  • Kong Ingress Controller
  • Kong Gateway Operator
  • Insomnia
  • Kuma

  • Docs contribution guidelines
  • 3.10.x (latest)
  • 3.9.x
  • 3.8.x
  • 3.7.x
  • 3.6.x
  • 3.5.x
  • 3.4.x (LTS)
  • 3.3.x
  • 2.8.x (LTS)
  • Archive (3.0.x and pre-2.8.x)
  • Introduction
    • Overview of Kong Gateway
    • Version Support Policy
    • Stages of Software Availability
    • Changelog
  • Install and Run
    • Overview
    • Kubernetes
    • Helm
    • OpenShift with Helm
    • Docker
    • Amazon Linux
    • CentOS
    • Debian
    • RHEL
    • Ubuntu
    • Migrating from OSS to EE
    • Upgrade Kong Gateway
    • Upgrade Kong Gateway OSS
    • Upgrade from 2.8 LTS to 3.4 LTS
  • Get Started
    • Quickstart Guide
      • Configuring a Service
      • Configuring a gRPC Service
      • Enabling Plugins
      • Adding Consumers
    • Comprehensive Guide
      • Prepare to Administer
      • Expose your Services
      • Protect your Services
      • Improve Performance
      • Secure Services
      • Set Up Intelligent Load Balancing
      • Manage Administrative Teams
      • Publish, Locate, and Consume Services
  • Plan and Deploy
    • Running Kong as a Non-Root User
    • Resource Sizing Guidelines
    • Hybrid Mode
      • Deploy Kong Gateway in Hybrid Mode
    • Kubernetes Deployment Options
    • Control Kong Gateway through systemd
    • Performance Testing Framework
    • DNS Considerations
    • Default Ports
    • Licenses
      • Access Your License
      • Deploy Your License
      • Monitor License Usage
    • Security
      • Start Kong Gateway Securely
      • Keyring and Data Encryption
      • Kong Security Update Process
      • Secrets Management
        • Getting Started
        • Advanced Usage
        • Backends
          • Environment Variables
          • AWS Secrets Manager
          • GCP Secret Manager
          • HashiCorp Vault
        • Reference Format
  • Configure
    • Authentication and Authorization
      • Authentication Reference
      • OpenID Connect Plugin
        • OpenID Connect with Curity
        • OpenID Connect with Azure AD
        • OpenID Connect with Google
        • OpenID Connect with Okta
        • OpenID Connect with Auth0
        • OpenID Connect with Cognito
        • OpenID Connect Plugin Reference
      • Allowing Multiple Authentication Methods
      • Auth for Kong Manager
        • Create a Super Admin
        • Configure Networking
        • Configure Kong Manager to Send Email
        • Reset Passwords and RBAC Tokens
        • Configure Workspaces
        • Basic Auth
        • LDAP
        • OIDC
        • Sessions
      • Role-based Access Control (RBAC)
        • Add a Role
        • Add a User
        • Add an Admin
      • Mapping LDAP Service Directory Groups to Kong Roles
    • Configure gRPC Plugins
    • GraphQL Quickstart
    • Logging Reference
    • Network and Firewall
  • Dev Portal
    • Overview
    • Enable the Dev Portal
    • Structure and File Types
    • Portal API Documentation
    • Working with Templates
    • Using the Editor
    • Configuration
      • Authentication
        • Basic Auth
        • Key Auth
        • OIDC
        • Sessions
        • Adding Custom Registration Fields
      • SMTP
      • Workspaces
    • Administration
      • Manage Developers
      • Developer Roles and Content Permissions
      • Application Registration
        • Authorization Provider Strategy
        • Enable Application Registration
        • Enable Key Authentication for Application Registration
        • External OAuth2 Support
        • Set up Okta and Kong for external OAuth
        • Set Up Azure AD and Kong for External Authentication
        • Manage Applications
    • Customization
      • Easy Theme Editing
      • Migrating Templates Between Workspaces
      • Markdown Rendering Module
      • Customizing Portal Emails
      • Adding and Using JavaScript Assets
      • Single Page App in Dev Portal
      • Alternate OpenAPI Renderer
    • Helpers CLI
  • Monitor
    • Kong Vitals
      • Metrics
      • Reports
      • Vitals with InfluxDB
      • Vitals with Prometheus
      • Estimate Vitals Storage in PostgreSQL
    • Prometheus plugin
    • Zipkin plugin
  • Reference
    • Admin API
      • DB-less Mode
      • Declarative Configuration
      • Supported Content Types
      • Information Routes
      • Health Routes
      • Tags
      • Service Object
      • Route Object
      • Consumer Object
      • Plugin Object
      • Certificate Object
      • CA Certificate Object
      • SNI Object
      • Upstream Object
      • Target Object
      • Vaults Beta
      • Licenses
        • Licenses Reference
        • Licenses Examples
      • Workspaces
        • Workspaces Reference
        • Workspace Examples
      • RBAC
        • RBAC Reference
        • RBAC Examples
      • Admins
        • API Reference
        • Examples
      • Developers
      • Consumer Groups
        • API Reference
        • Examples
      • Event Hooks
        • Event Hooks Reference
        • Examples
      • Audit Logging
      • Keyring and Data Encryption
      • Securing the Admin API
    • DB-less and Declarative Configuration
    • Configuration Reference
    • CLI Reference
    • Load Balancing Reference
    • Proxy Reference
    • Rate Limiting Library
    • Health Checks and Circuit Breakers Reference
    • Clustering Reference
    • Plugin Development Kit
      • kong.client
      • kong.client.tls
      • kong.cluster
      • kong.ctx
      • kong.ip
      • kong.log
      • kong.nginx
      • kong.node
      • kong.request
      • kong.response
      • kong.router
      • kong.service
      • kong.service.request
      • kong.service.response
      • kong.table
      • kong.vault
    • Plugin Development Guide
      • Introduction
      • File structure
      • Implementing custom logic
      • Plugin configuration
      • Accessing the datastore
      • Storing custom entities
      • Caching custom entities
      • Extending the Admin API
      • Writing tests
      • (un)Installing your plugin
    • Plugins in Other Languages
    • File Permissions Reference
enterprise-switcher-icon Switch to OSS
On this pageOn this page
  • Quick guide
  • CORS
    • Understanding CORS
    • CORS in the context of Kong Gateway
    • Troubleshooting
  • Cookies
    • Understanding cookies
    • Cookies in the context of Kong Gateway
    • Troubleshooting
You are browsing documentation for an older version. See the latest documentation here.

DNS Considerations for Kong Gateway

Kong Gateway provides web applications that must be able to interact with other Kong services to function properly: Kong Manager must be able to interact with the Admin API, and the Dev Portal must be able to interact with the Portal API. These applications are subject to security restrictions enforced by browsers, and Kong must send appropriate information to browsers in order for them to function properly.

These security restrictions use the applications’ DNS hostnames to evaluate whether the applications’ metadata satisfies the security constraints. As such, you must design your DNS structure to meet the requirements.

Quick guide

It is recommended you read through this document to understand why these requirements exist and how they function. In brief, your environment must meet one of the two criteria below:

  • Kong Manager and the Admin API are served from the same hostname, typically by placing the Admin API under an otherwise unused path, such as /_adminapi/.
  • Kong Manager and the Admin API are served from different hostnames with a shared suffix (e.g. kong.example for api.admin.kong.example and manager.admin.kong.example). Admin session configuration sets cookie_domain to the shared suffix.

The same applies to the Portal API and Dev Portal.

The first option simplifies configuration in kong.conf, but requires an HTTP proxy in front of the applications (because it uses HTTP path-based routing). The Kong proxy can be used for this. The second option requires more configuration in kong.conf, but can be used without proxying the applications.

CORS

Understanding CORS

Cross-Origin Resource Sharing, or CORS, is a set of rules for web applications that make requests across origins, i.e. to URLs that do not share the same scheme, hostname, and port as the page making the request. When making a cross-origin request, browsers send an Origin request header, and servers must respond with a matching Access-Control-Allow-Origin (ACAO) header. If the two headers do not match, the browser will discard the response, and any application components that require that response’s data will not function properly.

For example, the following request/response pairs have matching CORS headers, and will succeed:

GET / HTTP/1.1
Host: example.com
Origin: http://example.net

HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://example.net
GET / HTTP/1.1
Host: example.com
Origin: http://example.net

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *

* indicates that any origin is allowed.

These requests do not have a matching pair of CORS headers, and will fail:

GET / HTTP/1.1
Host: example.com
Origin: http://example.net

HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://badbadcors.example
GET / HTTP/1.1
Host: example.com
Origin: http://example.net

HTTP/1.1 200 OK

Missing CORS headers when CORS headers are expected results in failure.

CORS in the context of Kong Gateway

Kong Manager and the Dev Portal operate by issuing requests to their respective APIs using JavaScript. These requests may be cross-origin depending on your environment.

Kong’s services determine what CORS headers to send based on various location hint settings in kong.conf. The Admin API obtains its ACAO header value from admin_gui_url and the Portal API obtains its header value from the information in the portal_gui_protocol, portal_gui_host, and portal_gui_use_subdomains settings. You may optionally specify additional Portal API origins using portal_cors_origins.

You can configure your environment such that these requests are not cross-origin by accessing both the GUI and its associated API via the same hostname, e.g. by accessing Kong Manager at https://admin.kong.example/ and the Admin API at https://admin.kong.example/_api/. This option requires placing a proxy in front of both Kong Manager and the Admin API to handle path-based routing; you can use Kong’s proxy for this purpose. Note that the GUIs must be served at the root of their domains; you cannot place the APIs at the root and the GUI under a path.

Troubleshooting

CORS errors are shown in the browser developer console (for example, see documentation for Firefox and Chrome) with explanations of the specific issue. ACAO/Origin mismatches are most common, but other error conditions can appear as well.

For example, if you have mistyped your admin_api_uri, you will see something like the following:

Access to XMLHttpRequest at 'https://admin.kong.example' from origin 'https://manager.kong.example' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: The 'Access-Control-Allow-Origin' header has a value 'https://typo.kong.example' that is not equal to the supplied origin.

These errors are generally self-explanatory, but if the issue is not clear, check the Network developer tool, find the requests for the path in the error, and compare its Origin request header and Access-Control-Allow-Origin response header (it may be missing entirely).

Cookies

Understanding cookies

Cookies are small pieces of data saved by browsers for use in future requests. Servers include a Set-Cookie header in their response headers to set cookies, and browsers include a Cookie header when making subsequent requests.

Cookies are used for a variety of purposes and offer many settings to tailor when a browser will include them to fit a particular use case. Of particular interest are the following directives:

  • Cookie scope, defined by the cookie’s Domain and Path directives. Absent these, cookies are sent only to the hostname that created them: a cookie created by example.com will not be sent with a request to www.example.com. When Domain is specified, cookies are sent to that hostname and its subdomains, so a cookie from example.com with Domain=example.com will be sent with requests to www.example.com.
  • The Secure directive, which determines whether a cookie can be sent over an unencrypted (HTTP rather than HTTPS) connection. A cookie with Secure cannot be sent over HTTP, and must be set using HTTPS.
  • The SameSite directive, which controls when a cookie can be sent with cross-origin requests. Note that cookies have a different notion of cross-origin than CORS and check against the domain suffix: while example.com sending a request to api.example.com is cross-origin for the purposes of CORS, a cookie with Domain=example.com is considered same-site for requests to api.example.com. SameSite=Strict cookies are only sent with same-site requests, Lax are sent when navigating to a link from another site, and None are sent with all cross-origin requests.

Cookies in the context of Kong Gateway

After you log in to Kong Manager or the Dev Portal, Kong stores session information in a cookie to recognize your browser during future requests. These cookies are created using the session plugin (via admin_gui_session_conf) or OpenID Connect plugin. Configuration is more or less the same between each–the OpenID Connect plugin contains an embedded version of the session plugin, so while cookie handling code is the same, it is configured directly in the OpenID Connect plugin settings (admin_gui_auth_conf).

  • cookie_name does not affect where the cookie is used, but should be set to a unique value to avoid collisions: some configurations may use the same cookie_domain for both admin and Portal cookies, and using the same name for both would then cause their cookies to collide and overwrite one another.
  • cookie_domain should match the common hostname suffix shared by the GUI and its API. For example, if you use api.admin.kong.example and manager.admin.kong.example for the Admin API and Kong Manager, cookie_domain should be admin.kong.example.
  • cookie_samesite should typically be left at its default, strict. none is not necessary if you have your DNS records and cookie_domain set following the examples in this document. off is only needed if the GUI and API are on entirely separate hostnames, e.g. admin.kong.example for the API and manager.example.com for Kong Manager. This configuration is not recommended because off opens a vector for cross-site request forgery attacks. It may be needed in some development or testing environments, but should not be used in production.
  • cookie_secure controls whether cookies can be sent over unsecured (plaintext HTTP) requests. By default, it is set to true, which does not permit sending the cookie over unsecured connections. This setting should also remain on the default, but may be disabled in some development or testing environments where HTTPS is not used.

OpenID Connect uses the same settings, but prefixed with session_, e.g. session_cookie_name rather than cookie_name.

Dev Portal configuration does not differ significantly from Kong Manager configuration, but is configured per workspace under the Portal > Settings section of Kong Manager, in the “Session Config (JSON)” field.

As with CORS, the above is not necessary if both the GUI and API use the same hostname, with both behind a proxy and the API under a specific path on the hostname.

Troubleshooting

Issues with session cookies broadly fall into cases where the cookie is not sent and cases where the cookie is not set. The network (for example, see documentation for Firefox or Chrome) and application/storage (see documentation for Firefox or Chrome) developer tools can assist with investigating these.

In the network tool, selecting individual requests will show their request and response headers. Successful authentication requests should see a Set-Cookie response header including a cookie whose name matches cookie_name setting, and subsequent requests should include the same cookie in the Cookie request header.

If Set-Cookie is not present, it may be being stripped by some intermediate proxy, or may indicate that the authentication handler encountered an error. There should typically be other evidence in the response status and body in the event of an error, and possible additional information in Kong’s error logs.

If the cookie is set but not sent, it may have been deleted or may not match requests that need it. The application/storage tool will show current cookies and their parameters. Review these to see if your requests do not meet the criteria to send the cookie (e.g. the cookie domain is not a suffix for a request that requires the cookie, or is not present) and adjust your session configuration accordingly.

If cookies are not present in application/storage, but were previously set with Set-Cookie, they may have since been deleted, or may have expired. Review the Set-Cookie information to see when the cookie was set to expire and subsequent requests to determine if any other response has issued a Set-Cookie that deleted it (by setting expiration to a date in the past).

This troubleshooting information may not immediately indicate the cause of the issue, but can help Kong Support pinpoint the cause. Please provide it in tickets if possible.

Thank you for your feedback.
Was this page useful?
Too much on your plate? close cta icon
More features, less infrastructure with Kong Konnect. 1M requests per month for free.
Try it for Free
  • Kong
    Powering the API world

    Increase developer productivity, security, and performance at scale with the unified platform for API management, service mesh, and ingress controller.

    • Products
      • Kong Konnect
      • Kong Gateway Enterprise
      • Kong Gateway
      • Kong Mesh
      • Kong Ingress Controller
      • Kong Insomnia
      • Product Updates
      • Get Started
    • Documentation
      • Kong Konnect Docs
      • Kong Gateway Docs
      • Kong Mesh Docs
      • Kong Insomnia Docs
      • Kong Konnect Plugin Hub
    • Open Source
      • Kong Gateway
      • Kuma
      • Insomnia
      • Kong Community
    • Company
      • About Kong
      • Customers
      • Careers
      • Press
      • Events
      • Contact
  • Terms• Privacy• Trust and Compliance
© Kong Inc. 2025