Gateway Management
The gateway (nginx) is the single entry point of the whole deployment: except for the gateway, containers publish no ports to the host by default, and all external traffic is distributed and proxied by the gateway by domain. This page covers domain binding, CDN fronting, origin-pull tokens, and external endpoint exposure; per-service port exposure levels (off / local / public) are covered in Configuration and Troubleshooting - Port Exposure.
Domain Binding and CDN Fronting
The gateway supports the following binding targets:
| Target | Purpose |
|---|---|
| ui-admin | Admin portal |
| ui-merchant | Merchant portal |
| h5 | H5 app |
| backend | Backend API |
| app | Mobile API (dedicated entry for mini programs / apps) |
| artemis | Artemis console |
Enter bare domains only — no protocol, no path.
The Mobile API domain is a dedicated entry for mini programs and apps: once bound, it always admits the mini-program/app session API family plus the cashier open API (/unipay), regardless of the "External Endpoints" toggles; without it, mini programs and apps reach the backend through the backend API domain, governed by the "Mini program / APP API" toggle under External Endpoints. The HTTPS prerequisite is the same as the backend domain — the outer CDN / gateway layer must serve HTTPS, since WeChat / Alipay mini programs only accept HTTPS endpoints. To use it, enter this domain as the API base URL when building a mini program on the panel's "Mobile Management" page (leave it empty to keep the backend API domain default).
Access Modes
The gateway origin carries no certificates and always listens for origin-pull traffic over HTTP on port 80; HTTPS is terminated uniformly by the outer CDN / gateway layer (certificate issuance, renewal, and validation all happen in the outer console). There are two access modes:
| Mode | Behavior | Fits |
|---|---|---|
| Direct to origin (default) | The domain resolves straight to the server; the gateway does not check the request origin | No CDN, intranet, or temporary integration |
| Via CDN / outer gateway origin-pull | Each bound-domain entry only lets through requests carrying the correct origin-pull token; everything else gets 404 | Production, domain already on a CDN |
CDN Onboarding Checklist
After switching to "Via CDN / outer gateway origin-pull", follow the checklist shown on the panel's "CDN Fronting" page:
- Configure HTTPS certificates for each bound domain in the CDN console (free certificates are fine);
- Choose HTTP as the origin-pull protocol and set the origin-pull port to the gateway listening port (default 80);
- Point domain resolution at the CNAME assigned by the CDN;
- If the CDN provider publishes its origin-pull ranges (Alibaba Cloud / Tencent Cloud, etc.), allow only those ranges on port 80 in the cloud security group (cloud-side operation), layering it on top of the origin-pull token.
Configure the origin-pull header before switching
After you switch to CDN origin-pull mode and apply the gateway, domain access that resolves directly to this server is rejected with 404 until the origin-pull header is configured in the CDN console — this is the intended protection. The panel asks for confirmation when switching.
Origin-Pull Token
With CDN origin-pull mode enabled, the panel generates an origin-pull token. Configure it in the CDN console as the value of the custom origin-pull header X-Daxpay-Origin: each bound-domain entry only lets through requests carrying the correct token, preventing forged Host requests from bypassing the CDN straight to the origin.
- Only bound-domain entries take part in the check: direct entries for merchant APIs and channel callbacks do not validate the token (callback servers do not send custom headers, so they must be allowed through);
- after regenerating the token you must click "Apply Gateway Configuration" for it to take effect; the old token stops working immediately, and the CDN console header must be updated in sync — otherwise CDN origin-pull requests get 404 and the site goes down at once;
- when a backend API domain is bound, that domain must CNAME to the CDN and carry the origin-pull header, or WeChat / Alipay and other channel callbacks cannot reach the origin;
- the Artemis console domain should not go through a CDN (most CDNs support WebSocket poorly and the console's live views may misbehave) — keep it intranet-only or manage it through an SSH tunnel.
After saving domains, access modes, and endpoint toggles, click "Apply Gateway Configuration" to render the nginx configuration and reload it into effect.
External Endpoints
The gateway admits external requests by path prefix under "Gateway Management → External Endpoints"; anything not admitted is rejected. Default state of the four endpoint groups:
| Endpoint group | Purpose | Default |
|---|---|---|
| /unipay | Merchant open API | On |
| /unipay/callback | Channel callbacks | On |
| /app-* | Mini program / APP API: session APIs for the admin / merchant mini programs and apps | On |
| /epay | EPay-compatible API | Off |
Mini program / APP API covers the whole set of backend endpoints a mini program or app needs to sign in and run (login, notices, dictionaries, file upload, etc.) and only applies to the backend API domain line. There are three access routes; the status line at the bottom of the toggle card always shows the one currently in effect:
- Compatible route (default): leave the API base URL empty when building a mini program (the backend API domain is used); with the toggle on, sign-in works out of the box;
- Dedicated route: a Mobile API domain is bound and entered as the API base URL at build time — always open, unaffected by this toggle; after every deployed client has switched over, turning the toggle off is recommended so sign-in endpoints are only exposed via the dedicated domain;
- Broken route: with the toggle off and no Mobile API domain bound, mini programs and apps cannot sign in — the panel asks for confirmation before you turn the toggle off.
When accessing directly by IP, this endpoint group always returns 404 (protecting sign-in endpoints from brute force, same stance as the permanent /admin block), regardless of any toggle.
Management and debug paths such as /admin/, /mch/, /demo/, /test/, /swagger-ui/ stay blocked. Before going live, review the endpoint toggles, and restrict sources with domains, gateway rules, and a firewall.