# ArgoX: Xray proxy deployed through Cloudflare Argo tunnel without a domain or SSL certificate

> ArgoX combines Xray with Cloudflare Argo tunnel to route proxy traffic through Cloudflare's network, keeping the server IP out of client configurations and requiring no domain or certificate. A shell script installs up to 12 selectable protocols and generates subscriptions for multiple proxy clients.

**fscarmen/ArgoX** — ArgoX (Argo + Xray) is a one-click multi-protocol script based on the Xray core, supporting Reality, Hysteria2, VLESS, VMess, Trojan, Shadowsocks, XHTTP and over a dozen other protocols, paired with Cloudflare Argo tunnels and built-in custom WARP routing (by domain/geosite/geoip). Supports multi-client subscriptions (Clash, V2rayN, Throne, ShadowRocket, sing-box), with no domain or certificate required.

- Repository: https://github.com/fscarmen/ArgoX
- Website: https://fscarmen.cloudflare.now.cc/
- Stars: 2,033 · Forks: 663
- Language: Shell
- License: GPL-3.0
- Published: 2026-10-11 · Updated: 2026-10-11 · Language: en
- Canonical page: https://hysenlabs.com/projects/fscarmen-argox

## ArgoX binds Xray to localhost and routes all proxy traffic outward through Cloudflare Argo

When Xray listens on a public IP, that IP appears in every client configuration file and is directly reachable from the network. ArgoX removes that exposure by configuring Xray's inbound listeners to accept connections only from the localhost interface and opening an Argo tunnel to carry all client-originated traffic. Client configurations carry only Cloudflare-owned hostnames, not the server's own IP address.

No proxy port is exposed on the public network. A firewall audit of the VPS shows no listening proxy service on any public interface after installation, because cloudflared owns the outward-facing connection and Xray never opens one. This also means the server cannot be DDoS'd directly through the proxy port, and Cloudflare's full range of entry ports is available rather than only port 443.

ArgoX is GPL-3.0 licenced, distributes via the script file argox.sh rather than through GitHub releases, and was last pushed on 2026-10-03.

Obtaining a domain and submitting a certificate request are not prerequisites for any of the 12 protocols. Temporary tunnels work without any registration. Permanent tunnels are available through three paths: a Cloudflare Token, the cloudflared CLI or the Cloudflare API, and any of the three can be switched after installation with `argox -t`.

## Argo opens two reverse links per connection to nearby Cloudflare datacenters, not one

A standard CDN origin-pull connects the VPS to a single Cloudflare datacenter. Each Argo connection instead opens two reverse links, both pointing to the datacenters nearest to the connecting user. Traffic between the user and the VPS stays on Cloudflare's private backbone rather than crossing third-party transit links. This two-link architecture is specific to the Argo tunnel protocol and is not how standard CDN origin-pull connections behave, where all traffic enters the origin through one fixed link.

TLS handling works differently from a standard Xray setup as well. Xray delivers plain WebSocket or XHTTP streams, and Cloudflare's edge terminates TLS before forwarding to the origin. Avoiding the double-TLS pattern that some setups use reduces per-connection CPU overhead on the VPS and eliminates the extra handshake round trip.

For protocols 4 through 8 in the ArgoX table, all inbound traffic arrives through an Nginx path-routing layer before cloudflared forwards it to Xray. Nginx reads the path prefix and dispatches to the correct Xray inbound. A change to either the Nginx configuration or the cloudflared service affects all eight tunnel-based protocols at once, since they share this routing chain.

Direct-connect protocols (1, 3 and 9 through 12) bypass the Argo tunnel entirely and bind to their own ports, coexisting with the tunnel protocols on the same server.

## Install argox.sh and manage protocols after deployment with argox -r and argox -t

The top-level repository contains the install script `argox.sh` and a `config.conf` file. Two install modes are available: an interactive mode that walks through configuration choices and a non-interactive rapid mode for scripted deployments. Both commands are in the full README; the quick start headings visible here do not reproduce them.

After installation, the `argox` command is available as a system shortcut. Protocols can be added or removed at any time:

```bash
argox -r
```

Adding or removing a protocol through this menu reconfigures both the port assignments and Nginx's routing paths without requiring a restart of the installed services. The update notes describe this as zero-downtime hot reload.

The tunnel type switches between temporary and permanent Argo:

```bash
argox -t
```

The settings menu covers a range of post-install modifications:

```bash
argox -d
```

Through `argox -d`, an operator can assign independent ports to individual protocols, change the preferred CDN address, update WARP routing rules and reconfigure Hysteria2 bandwidth limits. Traffic statistics for Xray are accessible through a menu option inside `argox -d` and through the `-n` flag in the post-install management interface.

The project's companion site at fscarmen.cloudflare.now.cc assists with obtaining the JSON configuration needed for a fixed Argo tunnel.

## Row 2 in the protocol table appears twice, and the NAT relay sub-mode and port hopping cannot run together

The protocol table lists 13 rows but numbers them 1 through 12. Row 2 appears twice: once for Hysteria2 (plain UDP with optional port hopping) and once for the Hysteria2 NAT relay sub-mode, indicated in the table with a "└" character. ArgoX supports 12 protocols, and the table confirms that count. The relay sub-mode is a configuration variant of Hysteria2, not a thirteenth separate protocol.

The relay sub-mode and port hopping are mutually exclusive. When switching between them, both the install flow and the `argox -d` menu prompt for confirmation before making the change. Only one can be active at a time on a given Hysteria2 installation.

The distinction matters for deployment planning. Port hopping sends UDP datagrams across a range of ports rather than a fixed one, which distributes traffic to evade single-port blocking. The NAT relay sub-mode routes traffic through a public relay server to accomplish NAT hole punching for networks that block direct UDP. Choosing between them depends on which blocking problem the deployment faces.

All 12 protocol slots can be enabled simultaneously on one VPS. Protocols 4 through 8 share the Argo tunnel inbound while the direct-connect protocols run their own ports, so the two groups do not interfere with each other as long as port assignments do not overlap.

## Reality and self-signed certificate protocols connect directly without the Argo tunnel

Four protocols in the table bypass Cloudflare entirely: VLESS with XHTTP HTTP/2 Reality, VLESS with XHTTP HTTP/3 Direct, Trojan Direct and Shadowsocks 2022 Direct. Two others, VLESS with Reality Vision and VLESS with Reality gRPC, also connect directly. These six direct-connect protocols expose the server IP in the client configuration, unlike the tunnel-based protocols.

The self-signed certificate protocols (Trojan Direct, XHTTP HTTP/3 Direct and Hysteria2 in either sub-mode) have certificates generated and managed automatically. Changing the TLS domain name triggers automatic certificate regeneration and updates the associated client fingerprint configuration.

Reality-based protocols work by borrowing a TLS fingerprint from a legitimate public domain. Clients send a TLS ClientHello that matches the fingerprint of a real site while the server routes the connection to Xray's inbound. The `minClientVer` field that previously gated which clients could connect has been removed from `realitySettings`. Clash's `reality-opts` now includes `support-x25519mlkem768` as a required configuration field following recent Xray compatibility changes.

Running direct-connect and tunnel-based protocols concurrently on one installation is fully supported because the two groups use separate inbound paths, and Nginx dispatches for tunnel protocols without touching the ports used by direct-connect protocols.

## Subscriptions generate for eight client formats and VMess none/zero encoding will be removed at end of year

Each ArgoX installation exposes subscription endpoints through the Argo tunnel URL, under a path formed from the tunnel domain and the installation UUID. A subscription index at the root of that path lists all available formats: base64 for generic use, Clash/Mihomo, V2rayN, Throne, sing-box for desktop, sing-box for mobile, Shadowrocket and a QR code format. Multiple client formats co-exist on the same installation without reconfiguration.

For security, subscription endpoints return fabricated metadata rather than real server information when converted through the API path, so the actual node details are not visible from the subscription URL alone.

VMess none/zero encryption is being rewritten automatically in existing subscription files to the `auto` cipher method. Support for none/zero encoding will be removed after December 31, 2026. Throne clients, which do not accept `auto`, receive `aes-128-gcm` as the fallback encoding instead.

Custom WARP routing lets an operator split outbound traffic by domain name, geosite category or geoip category. Separate WARP-IPv4 and WARP-IPv6 outbound paths are available. The routing rules live in the Xray outbound configuration and can be modified through `argox -d`.

## All tunnel-based protocols share a single Cloudflare inbound and fail together if Argo is blocked

Protocols 4 through 8 all enter through the Argo tunnel. That shared inbound is also the shared failure point. A Cloudflare policy change, a tunnel interruption or a network block of cloudflared's outbound connections takes down all five tunnel-based protocols simultaneously. Direct-connect protocols continue working because they have independent inbounds, but anyone connecting through a tunnel-based protocol loses access until the tunnel is restored.

This is not a hypothetical limitation. Cloudflare reserves the right to terminate tunnels for policy violations, and the cloudflared process that manages the tunnel must stay running continuously. The `argox -d` management menu includes tunnel management options, but recovery from a terminated tunnel requires re-registering or switching to a different tunnel approach.

The companion site at fscarmen.cloudflare.now.cc is also Cloudflare-hosted. The Cloudflare API path for automatic tunnel creation depends on Cloudflare API access. These additional dependencies mean that a deployment built on ArgoX is structurally tied to Cloudflare at more than one layer.

Forking and distributing a modified copy of argox.sh requires making the modified source available under the same terms; operators who run the script unchanged are not affected by this obligation. The repository has no version markers, so there is no mechanism to pin installations to a specific commit through GitHub tooling.

## Conclusion

ArgoX suits operators who want multiple proxy protocols on one VPS without advertising the server IP and without managing a domain or certificate chain. The Cloudflare dependency is real: if Cloudflare blocks or closes the tunnel, every tunnel-based protocol goes down together because they share the same Argo inbound. Before deploying, read the full README install section for the current command, since it is not summarized in the quick start headings visible here, and verify that the target VPS can reach Cloudflare's network before running the install script.

## FAQ

### What is ArgoX and how does it differ from a plain Xray setup?

ArgoX is a shell script that installs Xray and routes all proxy traffic through a Cloudflare Argo reverse tunnel. A plain Xray install exposes the server IP in client configurations; ArgoX keeps client configurations to Cloudflare hostnames only, and no proxy port is exposed publicly.

### Does ArgoX require a domain name or SSL certificate?

No. Tunnel-based protocols need neither, because TLS is handled by Cloudflare. Direct-connect protocols that use self-signed certificates have those generated and maintained automatically by ArgoX, including regeneration when the TLS domain changes.

### How do I add or remove a protocol after ArgoX is installed?

Run argox -r to open the protocol management menu. Port assignments and Nginx routing paths update automatically; no reinstall is needed.

### Which proxy client applications receive subscriptions from ArgoX?

ArgoX generates subscriptions for Clash, Mihomo, V2rayN, Throne, Shadowrocket, SFI, SFA and SFM. A subscription index is accessible at a URL combining the Argo tunnel domain with the installation UUID.

### Can the Hysteria2 NAT relay sub-mode and port hopping run at the same time in ArgoX?

No. The two Hysteria2 sub-modes are mutually exclusive. Switching between them requires confirmation in both the install flow and the argox -d menu, and only one can be active at a time.

## Sources

- [fscarmen/ArgoX on GitHub](https://github.com/fscarmen/ArgoX)
- [Issues](https://github.com/fscarmen/ArgoX/issues)
- [License: GPL-3.0](https://github.com/fscarmen/ArgoX/blob/main/LICENSE)
- [Project website](https://fscarmen.cloudflare.now.cc/)
- [README](https://github.com/fscarmen/ArgoX/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fscarmen-argox