lxhao61/integrated-examples: V2Ray, Xray, Caddy and Nginx Deployment Recipes

What lxhao61/integrated-examples actually ships

The repository is a set of directories, each named after a protocol combination, such as Xray(VLESS+Vision+TLS)+Nginx\Caddy or V2Ray(VMess+WebSocket)+Nginx\Caddy. Each directory holds server-side configuration for that combination. The README describes the project as sharing optimized configurations and optimal combinations, and it also states that it provides Caddy v2 files with specific plugins integrated. So there are two things here: example configurations, and Caddy builds that include plugins such as forwardproxy and caddy-trojan.

The intended reader is someone who already understands what V2Ray, Xray, Caddy and Nginx are and wants a working arrangement of them. The README opens by suggesting that people unfamiliar with this area start from simple deployments and move to complex ones. That is a fair description of the structure: single-application examples come first, then combined applications built around reverse proxying, XTLS Vision, or REALITY Vision. The single-letter labels used throughout (A through M, plus N and T) are shorthand for specific transports, and the README defines them in a short note at the end.

Port sharing, UDS connections and the SNI split

The central mechanism across the examples is that many applications share TCP and UDP port 443. Nginx or Caddy terminates TLS and decides where the traffic goes, either by SNI or by falling back after a failed protocol match. The README states that Xray examples use SNI-based splitting, and that fallback or split connections enable PROXY protocol support so the backend can see the original client address.

For local connections between the web server and the proxy core, the examples use Unix Domain Sockets rather than loopback TCP. Two variants appear. With Caddy, the README says the examples use abstract mode, which avoids filesystem paths and the permission questions that come with them. With Nginx, the Xray examples use an attached permission form for the socket, which the README presents as a simple way to resolve access rights for the listening process. Those are different answers to the same problem, and the choice is dictated by which web server you run.

The README also lists a set of properties the examples aim for: all non-RAW applications can be deleted, swapped or added without breaking the whole setup; all applications except mKCP use TCP/UDP 443 and do not interfere with each other; and camouflage sites support automatic HTTP to HTTPS redirect. The claim that an SSL/TLS assessment report is A+ is made by the README, not verified here, and it explicitly excludes examples using non-AES cipher suites.

Installing from the release and running a first Xray example

There is no install script. The README does not give a package command, a service unit or a bootstrap procedure. What it does provide is a Caddy build with plugins, distributed through the repository releases. The most recent release is tagged 20260605 and names Caddy_v2.11.4; the two before it are 20260517 (Caddy_v2.11.3) and 20260315 (Caddy_v2.11.2).

So the practical path is: pick the directory that matches your intended transport, copy its configuration files, install the Caddy binary from the matching release if your chosen example uses Caddy, and place the configuration where your web server expects it. The exact file names and paths are inside each directory rather than the README, so the first step is to open the directory listing.

If your example uses Nginx instead, the Caddy binary is irrelevant and you need the Nginx configuration from that same directory. The README does not document rollback, so keep the previous configuration files before replacing anything.

Where this repository will not help you

The examples assume a server with a domain, a working TLS certificate source, and, in many cases, the freedom to bind port 443 for both TCP and UDP. If your provider blocks or filters those ports, or if another service already owns them, the shared-port design that ties the examples together stops being an advantage.

The README also notes that the V2Ray and Xray examples configure BT traffic blocking, and points to a bt.json example under V2Ray(Other Configuration) for adjustments. That is a default you inherit unless you change it. Anyone expecting neutral forwarding behavior needs to look at that file.

Finally, the repository is a reference set. The README does not describe a support policy, a compatibility matrix between its configurations and specific Caddy or Xray versions, or an upgrade procedure for existing deployments. The release tags track Caddy versions, which suggests the Caddy builds are refreshed, but nothing in the README states that the surrounding configurations are re-tested against each new Caddy release.

How this differs from a single-binary proxy such as Hysteria alone

The repository includes a Hysteria example, described in the README as a proxy application based on a modified QUIC protocol. That is the contrast worth drawing. Hysteria is one process speaking one protocol over QUIC, and deploying it does not involve a web server, SNI splitting, or a certificate pipeline shared with a website.

The integrated-examples approach is the opposite: a general-purpose web server owns the port, serves a camouflage site, obtains and renews certificates, and routes protocol traffic to one or more backend cores. The README states that Caddy handles certificate application, renewal and reload automatically in the examples where Caddy provides TLS, and that Caddy's SNI splitting can share both TCP 443 and UDP 443, which is how the Hysteria example coexists with the rest.

The cost of that design is configuration surface. You maintain a web server config, one or more proxy core configs, and the socket or loopback plumbing between them. A single-binary deployment has far less to get wrong. The benefit is that a real website and several transports can sit on one address, and the README's point about CDN-relayed traffic still exposing the client's real IP is part of that.

Licence and the cost of keeping up

The repository is licensed GPL-3.0. That applies to the repository contents, which include configuration files and, per the README, Caddy builds with integrated plugins. Caddy itself and the plugins it links are separate projects with their own licences, and the README does not enumerate them, so if you redistribute a binary from the releases you need to check those upstream terms yourself. Nothing in this article is legal advice.

On maintenance cost, the last push to the default branch was on 2026-06-05, the same day as the 20260605 release. The release history shows Caddy version bumps roughly every few weeks in the period covered: 20260315, 20260517, 20260605. That pattern tells you the Caddy builds are the part that moves. It does not tell you the example configurations move with them. If you deploy one of these setups, treat the configuration as a fork you now own, because the README documents no upgrade path from one release to the next.

Editorial conclusion

Adopt this repository if you already run Nginx or Caddy and want a starting point for Xray or V2Ray configurations that share port 443, and if you are comfortable reading JSON and Caddyfile examples rather than running an installer. Do not adopt it if you need a supported product with a documented upgrade path, because the repository ships configuration examples and plugin-integrated Caddy builds, not a package. Before copying anything, check that the directory you pick matches your certificate source, your CDN usage and your transport choice, and confirm that the release tag you download names the Caddy version you intend to run.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. lxhao61/integrated-examples on GitHub
4. README
5. Releases