XHTTP-Installer: a one-command Ubuntu script that fronts a VLESS XHTTP proxy with a Vercel or Netlify relay

What the script installs

XHTTP-Installer is a bash script for Ubuntu 20.04 and later that stands up a proxy in one command.

bash <(curl -fsSL https://github.com/avacocloud/XHTTP-Installer/releases/latest/download/Deploy-Ubuntu.sh)

The endpoint it configures is Xray-core running VLESS over XHTTP transport with TLS on port 443. The distinctive part is the second layer: instead of clients connecting straight to your server, the script deploys a small relay, called relay.js in the architecture diagram, to the edge functions of Vercel or Netlify, and the client talks to that CDN domain. The README states the reasoning directly: a direct connection exposes the server IP, which can then be blocked, while traffic through a known platform's edge keeps the origin address out of sight. The client side uses ordinary proxy applications, with v2rayN, Nekoray and Hiddify named as the supported examples.

The eight phases

The README documents the run as eight phases. Phase one is a preflight that checks the operating system, root access, internet connectivity, whether ports 80 and 443 are free, and that DNS for your domain points at the server, with auto-fix offered when something is off. Phase two installs the toolchain automatically: Xray-core as the proxy kernel, acme.sh for certificates, Node.js and npm as the prerequisite for platform CLIs, the Vercel CLI or Netlify CLI depending on your choice, xray-knife for end-to-end testing, and curl, jq, unzip and screen as helpers. Phase three collects inputs interactively: platform choice, a domain such as ns.example.com, an optional SSL email, the Xray port defaulting to 443, the relay path defaulting to /api, and a required platform token. Phase four issues the certificate, phase five writes the Xray configuration, phase six deploys the relay, and the last phases run the end-to-end test and generate the client configuration.

Certificates, config and what you get at the end

Certificate issuance goes through acme.sh against Let's Encrypt, with the certificate files stored under /etc/ssl/xhttp/<domain>/ and automatic renewal enabled. Port 80 conflicts are handled by the auto-fix path. The Xray configuration is written to /usr/local/etc/xray/config.json with a freshly generated UUID, VLESS over XHTTP with TLS, correct permissions on the certificate files, and the service started and enabled through systemd, followed by a health check. On the CDN side, the flow for Vercel is login with your token, creating a project and setting the TARGET_DOMAIN environment variables before deploy, and Netlify works the same way through its CLI. When the end-to-end test passes, the script prints a vless:// link that carries the full client configuration, so the setup ends with something you can paste into v2rayN or Hiddify rather than a list of manual parameters.

What the releases fixed

Version 1.0.1, published on 2026-05-11, is a useful read because every fix is a real failure mode. On NAT servers such as AWS Lightsail, EC2 and GCP, hostname -I returns the private address, which caused a false DNS mismatch and an SSL abort; the fix fetches the public IPv4 from the AWS metadata API first, then falls back to ifconfig.me, ipify.org and icanhazip.com. A silent acme.sh install failure previously let the script continue and crash later with a missing file error; the binary is now verified after install, with a GitHub mirror as fallback and a hard exit with a clear message. The Netlify CLI installation failed on 512MB or 1GB VPS boxes due to memory limits, so there is now a four-stage fallback from a standard install, to a reduced-memory install, to a cache clean and retry, to an npx wrapper. And the end-to-end test previously ran after a fixed four second sleep before Xray had opened its SOCKS5 port, producing false HTTP 000 failures; it now polls port 10809 every second for up to twelve seconds. Version 1.0.2 on 2026-05-13 handles the acme.sh message about unchanged domains by reusing an existing certificate from disk or forcing re-issue, and supports both EC and RSA certificates from earlier runs.

Limits and prerequisites

The script assumes a Ubuntu 20.04 or later server with root access, ports 80 and 443 available, and DNS for your domain already pointed at it before the run. It is interactive in phase three, so it needs a real terminal session, and it requires a Vercel or Netlify token, meaning you need an account on the chosen platform and must be willing to deploy the relay project there under the platform's terms. The tool installation is broad, adding CLIs and utilities globally on your server, which is convenient on a dedicated box and presumptuous on a shared one. The relay depends on the CDN platform continuing to allow this use of edge functions on free plans, which is outside the project's control. Client compatibility is the usual modern XHTTP stack: the named applications are v2rayN, Nekoray and Hiddify, and older clients without XHTTP transport support will not work against this endpoint.

Compared with a plain Xray setup

The alternative is installing Xray-core yourself, writing the config.json by hand, obtaining a certificate with acme.sh or certbot, and pointing clients at the server domain directly. That is fewer moving parts, no CDN dependency, and full control, at the cost of an exposed origin IP and manual maintenance of exactly the steps this script automates. The relay architecture trades that simplicity for the hidden origin: the platform edge fronts the traffic, which also means your effective entry points are the CDN addresses and the server itself never needs to be public beyond serving the relay target. For a single-user personal setup on a small VPS, the script's automation is the practical draw; for anything shared or production-adjacent, a hand-maintained configuration you understand line by line is the better trade. The MIT licence and the small script footprint keep either path open, since the script is readable in one sitting.

Licence and upkeep

The project carries an MIT licence badge and is documented in Persian and English, with a Telegram channel as the community contact point. The repository itself shows two published releases, v1.0.1 and v1.0.2 in May 2026, both focused on installation reliability rather than new features, and the current release download is delivered as Deploy-Ubuntu.sh from the latest release URL, so the script always installs the newest version. The README is structured as a phase-by-phase walkthrough with architecture and phase diagrams, which makes the script's behavior predictable before you run it. There is no stated roadmap beyond the fixes, and the single-script shape means updates land as new script versions rather than dependency bumps, so checking the release notes before re-running on an existing server is the sensible habit.

Editorial conclusion

Take XHTTP-Installer if you want a personal VLESS+XHTTP endpoint on a cheap Ubuntu box without hand-writing Xray configs or certificate plumbing, and the relay architecture fits, since putting a Vercel or Netlify edge function in front is the whole point and costs nothing on the free tiers. Read the phases before running it anyway: it wants root, ports 80 and 443, DNS already pointed at the server, and an interactive session for the platform token and domain questions, and it installs a fair number of global tools on your server. The v1.0.1 and v1.0.2 fixes show the rough edges are the ones you would expect on NAT servers and low-RAM VPS boxes, and they are now handled, which is a decent sign for a script of this kind.

Frequently asked questions

Official sources

1. avacocloud/XHTTP-Installer on GitHub
2. Issues
3. README
4. Releases