Node Configuration
Path: Admin → Nodes → (node) → Proxy.
This view has an indicator at the top ("Wings proxy module status") that confirms whether the node responds to GET /. If it shows red/warning, check the Wings installation on that node before continuing.
Fields with active logic
| Field | What it does |
|---|---|
| Status (Enabled / Disabled) | Master switch. When set to Disabled, users on that node can't create new domains (the ones already active keep working). |
| Max domains per server | Cap on active domains per server. 0 = no limit. |
| Require domain ownership verification | When set to Required, every new domain goes into an awaiting dns state with a randomly generated token. The user has to create a _ TXT record with that value and click "Verify now"; only then does the domain move to pending and get applied on Wings. This prevents someone from pointing a domain they don't control at their own server. |
| Domains config directory | Folder on the node where Wings writes the nginx . files. Defaults to /. It has a "Test configuration" button next to it, which asks Wings to confirm live whether the node's nginx. is actually including that folder. Use it after any change here or in the node's nginx., before a client creates a domain: it's the way to catch the "domain shows Active but nginx never loads it" error (see Troubleshooting) without relying on someone noticing by accident. |
| Let's Encrypt (Allowed / Blocked) | Enables or blocks users from choosing letsencrypt mode when creating a domain. |
| Cloudflare (Allowed / Blocked) | Enables or blocks users from choosing cloudflare mode. |
| User-supplied certificate (custom) (Allowed / Blocked) | Enables or blocks users from pasting their own certificate and key (custom mode). See SSL modes. |
| Certbot account email | Email certbot uses to register the ACME account. Required if you allow Let's Encrypt. |
| Show nginx config path | Off by default. When it's off, the exact path of the generated . (e.g. /) isn't shown to the user under their domain, and it isn't sent by the API either (it's not just hidden on screen). That path is an internal server detail with no use to the end customer, and it can hint at what addon is running on the node. Only turn it on if you specifically want that transparency with your users. |
| Nginx reload command | The exact command Wings runs (via shell) every time it writes or removes a domain's .. Defaults to nginx -: the first half validates syntax, the second reloads; if you change this and the validation half fails, the reload half never runs and the domain stays in error. Only touch this if your node reloads nginx a different way (e.g. systemctl reload nginx). |
What is NOT configured here
The destination host and port (where nginx forwards the domain's traffic) is not a field on this screen. It's never free-text: it's always a real allocation already assigned to the server, chosen by the user when creating the domain, or the server's primary allocation if none was chosen. If the server has no allocation assigned, the job fails with:
Server, node, or allocation not found.
Assign an allocation to the server from Admin → Servers → (server) → Network and try creating the domain again.
Security warning: "Nginx reload command" is equivalent to root access on the node
Wings runs the value of this field as-is, through a shell (sh -), every time it applies or revokes a domain. There's no restriction on what it can contain: it's free text. This means any user with an administrator role in the panel can, through this field, run any command as the user Wings runs as on that node (usually root).
In practice: giving someone the panel's administrator role is equivalent to giving them root access over SSH to every node that panel manages, not just access to server management. This isn't a bug, it's the necessary trade-off of making the reload command configurable (different nodes reload nginx in different ways). Keep this in mind when deciding who gets that role.
Next: Permissions →