personal-edge-proxy separates how you get into the VPS from where the traffic leaves

Inbound redundancy and outbound identity are two different problems

The whole document is built on one distinction, stated as a rule in a callout: REALITY and Cloudflare Tunnel solve how traffic gets into the VPS, while WARP and a fixed SOCKS5 solve where the VPS sends it out.

The warning attached to that rule is the useful part. Adding REALITY does not make the exit IP that an AI service sees any cleaner. If the chain still ends at VPS Direct, the egress identity has not changed at all, no matter how many inbound protocols you added. Someone reading a tier list and picking the row with the most technologies in it would get exactly the wrong outcome.

The file is written in Chinese and is unusually careful about framing. It states plainly that the setup is not a guarantee of circumventing service terms and cannot promise that no account triggers risk controls, and it asks the reader to confirm the target service supports their region and follow its terms. It also gives the reason for the architecture in operational terms rather than conspiratorial ones: regional availability, data centre IP reputation, changing egress and risk challenges.

There is an AGENTS.md at the top of the repository, described as maintenance and deployment instructions for AI and agents, so the document is written with agent operated deployment in mind from the start.

Five tiers, ordered by the problem each one fixes

The tiers are presented as a way to judge what a layer actually solves, not as a mandatory install order.

Tier A is Hysteria2 straight to VPS Direct. It is the minimum, and the note is that AI services then see the VPS data centre egress directly, so a mediocre IP range reputation makes availability problems and challenges more likely.

Tier B adds REALITY as a backup inbound. Its entry says the egress is still VPS Direct, so egress side problems are essentially the same as A, and what it reduces is connection risk when UDP is unavailable.

Tier C sends designated AI traffic to WARP instead. That decouples AI from the native data centre egress, and the note calls it very practical and usually better suited to AI than A or B, with the added point that WARP does not need to take over the entire VPS.

Tier D adds a fixed SOCKS5 for Claude and Anthropic, and is marked as the author's most recommended practical tier: OpenAI and Gemini traffic through WARP, Claude and Anthropic through a fixed exit when needed.

Tier E adds REALITY or Cloudflare Tunnel as further backup inbounds, described as worthwhile when the network environment is complex or you often change Wi-Fi, campus or office networks.

WARP is positioned so its failure cannot take SSH down with it

The recommended shape keeps the server's own network on the native route and diverts only what Xray selects:

Linux default route to VPS native network

only Xray selected traffic
        |
        v
warp-official outbound
        |
        v SOCKS5
127.0.0.1:40000
        |
        v
warp-svc / MASQUE
        |
        v
Cloudflare WARP

Five reasons are given, and the second is the one that matters most operationally. AI traffic does not have to use the VPS data centre egress, and a WARP failure will not drag SSH, system updates and the upstream SOCKS5 down with it, because none of those sit behind the WARP tunnel. Routing can be per domain, reconnecting WARP does not require rebuilding client nodes, and the three egresses, Direct, WARP and fixed SOCKS5, can be tested independently.

The caveat is stated just as plainly: WARP is not a residential IP and cannot guarantee that any particular service will accept it. It is an independent and convenient Cloudflare egress, nothing more.

On the optional fixed layer, the document is careful in the same way. Claude and Anthropic traffic can be routed through a static SOCKS5 to a fixed public egress, which keeps that policy separate from HY2 or REALITY switching, VPS migration and WARP reconnects. But Claude is not, at the protocol level, required to have a residential IP, the fixed SOCKS5 is an optional strategy, SOCKS5 by itself is not an encrypted tunnel, and if the VPS or WARP egress already meets your needs you can leave the layer out.

A human does the first SSH login, then the agent takes over

There is a dedicated sequence for handing a server to an AI agent, and its first step is deliberately human. A person logs in once with the initial password or the provider console, generates a keypair locally, puts only the public key into the server's authorized_keys, and confirms key login works. Only then does Claude Code, Codex or another agent continue using the ssh that already works on the machine.

ssh-keygen -t ed25519

On Linux and macOS the key is copied with `ssh-copy-id root@YOUR_SERVER_IP`. On Windows PowerShell the equivalent is a single pipeline that creates the directory with a restrictive umask before appending:

Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub | ssh root@YOUR_SERVER_IP "umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys"

Two rules sit alongside those commands. Never copy SSH private keys or the VPS root password into chat, an issue or a public repository, and note that an agent which can already call your ssh, your SSH Agent or your `~/.ssh/config` does not need to know the private key content at all. And do not turn off password login until key login is verified, because that is how people lock themselves out of a machine they cannot reach.

The default file names are spelled out too: the private key stays on the local machine, the public key is the one that may be uploaded.

Fail closed instead of falling back to the data centre IP

For targets deliberately bound to a fixed egress, the design choice is to let the request fail:

fixed upstream unavailable
      |
      v
request fails

The alternative, an automatic fallback to VPS Direct, is rejected for a reason worth repeating in any similar setup: it can change the final egress without the user noticing. A configuration that quietly degrades to a different network identity is worse than one that stops, because nothing announces the change and the application simply behaves differently.

This is the same logic as the rest of the document's egress separation, applied to failure instead of to routing. Client and server responsibilities are split the same way: the client sends mainland China and private network traffic to DIRECT and everything that needs a proxy to the VPS, while the server's advanced routing sends ordinary traffic to VPS Direct, designated AI such as OpenAI and Gemini to WARP, and Claude and Anthropic to the optional fixed SOCKS5. The stated benefit of that split is that no client has to store WARP or upstream SOCKS5 credentials at all.

The examples are scrubbed, not copied: the pipeline from production to public file

The file is explicit that the production machine went through several rounds of experiments and that the repository examples are not verbatim copies of a working configuration. The path from one to the other is given as a sequence: verification on the live machine, a read only audit, a cross check against official documentation, redaction and cleanup of historical residue, and only then a public example.

Three example files come out of that pipeline. `examples/xray-server.example.jsonc` covers Hysteria2, REALITY, Direct, WARP, the optional fixed SOCKS5 and sample routing. `examples/v2rayn-hysteria2.example.md` is taken from the actual sing-box runtime structure that the current v2rayN produces when it activates a node. `examples/v2rayn-reality-vision.example.md` was cross checked against the v2rayN node library, the imported configuration and the current Xray fields.

The environment that was audited is given with versions: Ubuntu 24.04 LTS on the server with Xray 26.3.27, VLESS with REALITY and Vision on TCP 443, Hysteria2 on UDP 24443, and WARP through warp-svc Local Proxy exposed as SOCKS5 on 127.0.0.1:40000. The Windows client was v2rayN 7.24.2 with sing-box 1.13.14 active when Hysteria2 is in use, the Xray core for the REALITY configuration, and TUN plus Rule mode. Official references are cited for the Xray Hysteria inbound and transport, REALITY and RAW transports, and the Cloudflare WARP Linux client and its modes.

Eleven placeholders, a do not commit list, and no releases to pin

The security section is a checklist rather than advice. The list of things not to commit to a public repository covers real SSH private keys and root passwords, VLESS UUIDs, the Reality private key, the Reality shortId, the Hysteria2 password, TLS private keys, Cloudflare tokens, upstream SOCKS5 credentials, subscription URLs and production configurations.

The repository answers that with eleven placeholders used consistently: YOUR_SERVER_IP, YOUR_UUID, YOUR_REALITY_PRIVATE_KEY, YOUR_REALITY_PUBLIC_KEY, YOUR_SHORT_ID, YOUR_HY2_PASSWORD, YOUR_DOMAIN, YOUR_SERVER_NAME, YOUR_SOCKS_HOST, YOUR_SOCKS_USERNAME and YOUR_SOCKS_PASSWORD.

Two smaller observations. The repository has published no releases at all, so the audited versions, Xray 26.3.27 and v2rayN 7.24.2, are a claim about one machine at one moment rather than a pinned configuration anyone can reproduce from a tag.

And the port layout section makes a point that is easy to skim past: the layout is TCP 22 for SSH, TCP 443 for REALITY and UDP 24443 for Hysteria2, but if you deploy only Hysteria2 you do not need to open TCP 443 just because the repository contains a REALITY example. UDP 24443 was chosen after testing on one line and does not mean Hysteria2 requires it; if your route has stable UDP 443, use that instead. The port should follow what is actually reachable.

Editorial conclusion

This repository suits someone who already runs Xray or v2rayN and wants the routing decisions written down rather than rediscovered, and who can read Chinese or use a translator for a document where every caveat is precise. Three things to check first. The central claim is that REALITY and Cloudflare Tunnel change only inbound redundancy while WARP and a fixed SOCKS5 change the exit identity, so a tier that looks more private may not be. WARP is stated not to be a residential IP. And the document is explicit that none of this circumvents terms of service or prevents an account from tripping risk controls, so confirm your target service supports your region first.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. yding-git/personal-edge-proxy on GitHub