Feature Request: Automated Nginx and SSL Configuration

[alinasrollahzadeh405-sudo]

Is your feature request related to a problem?

Hi,

First of all, thank you for your great panel. It is very accessible and easy to use.

I have a suggestion to improve the user experience:
Currently, when we want to set up WebSocket or CDN configurations, we have to manually edit Nginx config files, which is complicated and time-consuming.

It would be amazing if the installation script could handle this automatically. For example, it could ask a few simple questions during the setup, such as:

1. Do you want to configure Nginx for WebSocket/CDN?
2. Which domain are you using?
3. Should it automatically install and set up SSL (Let's Encrypt)?

If the script handles the Nginx reverse proxy configuration and SSL setup behind the scenes, it would save a lot of time and prevent configuration errors.

Thank you for your hard work and for making the panel accessible.

Describe the solution you'd like

adding auto configurator for nginx in install.sh or x-ui.sh

Alternatives you've considered

No response

Concrete use case

No response

Mockups, screenshots, or examples

No response

Which parts of the panel would this affect?

No response

Are you willing to help?

• I'd like to implement this feature myself and open a PR.
• I can help test once a PR is open.

Before submitting

• I searched existing issues and this feature has not been requested.
• This feature request is written in English.

[github-actions]

Thanks for the suggestion. Here is what is already automated today versus the gap you have identified:

Already automated (no Nginx involved):

• install.sh already runs an interactive SSL wizard during install: it prompts for one of "Lets Encrypt for Domain", "Lets Encrypt for IP Address", "Custom SSL Certificate", or "Skip SSL" (install.sh, the ssl_choice menu starting around line 823). Options 1 and 2 drive acme.sh directly (standalone HTTP-01 on port 80) to issue and wire up a certificate for the panel itself, with no Nginx involved. It also supports unattended installs via NONINTERACTIVE=1 with an XUI_SSL_MODE=domain|ip|none variable.
• After install, the x-ui CLI menu options 20 (SSL Certificate Management) and 21 (Cloudflare SSL Certificate) provide the same for ongoing issuance, renewal, and DNS-01 wildcard certs. See docs.sanaei.dev/docs/config/ssl-certificates for the full flow.

Not automated today:

• Neither install.sh nor x-ui.sh installs or configures Nginx or any reverse proxy. The only Nginx-related code in x-ui.sh is a preset for the acme.sh --reloadcmd option (systemctl reload nginx ; x-ui restart), which assumes Nginx is already installed and running; it does not install or write a config for it. install.sh only references a reverse proxy in advisory text, for example as an alternative when SSL is skipped.
• A related tool already exists but is manual: the docs site has a Reverse Proxy Generator (docs.sanaei.dev/docs/operations/reverse-proxy) that generates an Nginx or Caddy server block, including the WebSocket Upgrade/Connection headers the panel needs, plus the matching certbot/acme.sh command, from a domain, port, and base path you enter. It runs entirely in the browser and only produces text to copy onto the server; it is not wired into install.sh or x-ui.sh, and installs or runs nothing for you.

So the gap you have identified is real: there is no scripted path that installs Nginx, writes the reverse-proxy block, and obtains and wires up a certificate for it, comparable to the existing direct-TLS wizard. A few points worth noting for whoever scopes this:

• install.sh already branches package managers per distro (apt, dnf, yum, pacman, apk) and init systems (systemd versus Alpine OpenRC) for its existing dependencies; Nginx install and configuration would need the same branching.
• It would not apply to the Docker image: the final stage of the Dockerfile intentionally installs only ca-certificates tzdata fail2ban bash curl openssl, no Nginx, and the docs already point Docker users at an external reverse proxy for TLS termination.
• Re-running the installer for upgrades would need to avoid overwriting an Nginx config a user may have edited by hand since.

No further information is needed to evaluate this request. Leaving it open as an enhancement for @MHSanaei to weigh in on scope and priority.

This reply was generated automatically by an AI workflow. A maintainer may follow up.