personal-edge-proxy: a multi-inbound, multi-outbound Xray setup for AI traffic
A practical multi-inbound, multi-outbound personal proxy setup with Xray, Hysteria2, REALITY Vision, WARP and optional static SOCKS5 routing.
At a glance
- What is it?
- The repository documents a personal proxy architecture built around Hysteria2 as the daily entry point, with WARP and an optional fixed SOCKS5 upstream reserved for AI services. It is a configuration pattern, not a packaged product.
- Who is it for?
- Adopt this if you already run a VPS for personal use and want a documented way to separate AI service traffic from your VPS native exit, with REALITY kept as an entry fallback rather than a fix for outbound reputation. Do not adopt it if you want a packaged installer, a dashboard or a one-command deploy: the repository is configuration examples plus docs, and the README explicitly says a single Hysteria2 inbound is enough if that is all you need.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 9 days ago.
- What is it written in?
- GitHub does not report a main language for this repository.
Answers come from the project's GitHub data, last synced on September 16, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What personal-edge-proxy actually solves
The repository is not a proxy server. It is one operator's documented answer to a narrower question: when a single cheap VPS is both the entry point and the exit point for everything, which parts of that chain should be split, and which parts are not worth splitting?
The split the README argues for is between entry and exit. REALITY and Cloudflare Tunnel are described as entry redundancy: they change how a client reaches the VPS. WARP and a fixed SOCKS5 upstream are outbound policy: they change which IP address the destination service sees. The README states this distinction directly, warning that adding REALITY does not make the exit IP look any cleaner if traffic still leaves via VPS Direct.
The audience is a single operator who already has, or is about to buy, a VPS and whose main workload is AI services such as ChatGPT, Codex, Gemini and Claude. The README frames the motivation in terms of regional availability, datacenter IP reputation, exit changes and risk-control challenges, and then explicitly disclaims any guarantee: it says the setup is not a way to avoid terms of service and cannot promise an account will not be challenged. That disclaimer is worth taking at face value. The repository gives you a topology to reason about, not a compliance argument.
Entry versus exit: the two axes of the architecture
The README lays the whole design out as one diagram. A client reaches the VPS over Hysteria2, and the VPS then decides where each flow leaves: ordinary traffic to VPS Direct, OpenAI/ChatGPT/Codex and Gemini/Google AI to Cloudflare WARP, and Claude/Anthropic optionally to a fixed SOCKS5 endpoint.
The WARP path is the most concrete mechanism in the repository. The documentation describes Xray selecting traffic by domain and sending it to a warp-official outbound, which speaks SOCKS5 to 127.0.0.1:40000, where warp-svc runs. The Linux default route is untouched, so SSH, system updates and the upstream SOCKS5 connection itself do not ride through WARP. The README lists five consequences of that isolation, and the fourth one is the practical one: reconnecting WARP does not require rebuilding client nodes.
The repository grades the design into five tiers, A through E, and the grading is honest about what each tier does not fix. Tier B adds a REALITY fallback entry but keeps VPS Direct as the exit, so the README says outbound-side problems are the same as tier A. Tier C introduces WARP for selected AI domains. Tier D adds the fixed SOCKS5 for Claude, and the README calls it the most recommended practical tier. Tier E adds more entry redundancy and is described as a bonus, most useful when you move between Wi-Fi, campus and corporate networks.
The architecture also pushes client-side work down to a minimum. Clients only decide direct versus proxied; the server holds the WARP and SOCKS5 credentials, so no laptop needs to store an upstream username or password.
Installing from the examples: SSH first, then HY2
There is no installer. The repository ships docs/, examples/ and an AGENTS.md file aimed at AI agents doing the deployment, and the README recommends a specific order: pick a VPS, verify SSH key login, deploy Hysteria2, verify from a client, then add WARP, then add the fixed SOCKS5 if needed.
The first step the README insists a human perform is the SSH bootstrap. Generate a key pair locally, copy only the public key to the server, and confirm key login works before letting an agent take over.
ssh-keygen -t ed25519
ssh-copy-id root@YOUR_SERVER_IP
ssh root@YOUR_SERVER_IPThe first command produces ~/.ssh/id_ed25519 and ~/.ssh/id_ed25519.pub. The second installs the public key on the server. The third is the verification step: if it drops you into a shell without asking for the root password, key login works. The README warns not to disable password login until that succeeds, and not to paste the private key or root password into a chat, an issue or a public repository.
Server-side configuration lives in examples/xray-server.example.jsonc, which the README says contains the HY2 and REALITY inbounds, Direct, WARP and optional Fixed SOCKS5 outbounds, and sample routing. It is JSONC, so comments are present, and every sensitive value is a placeholder such as YOUR_UUID, YOUR_REALITY_PRIVATE_KEY, YOUR_HY2_PASSWORD, YOUR_SERVER_NAME or YOUR_SOCKS_USERNAME. The README also states that the public examples are not a copy of the production configuration: they went through a read-only audit, a check against official documentation, and a scrubbing pass before publication. Treat them as a structural reference and expect to fill in your own values.
The port layout in the README is TCP 22 for SSH, TCP 443 for REALITY and UDP 24443 for HY2. It notes that 24443 was chosen after testing on the author's own line and is not a requirement, and that UDP 443 is fine if it is reachable on your network. If you only deploy HY2, you do not need to open TCP 443 just because the example contains a REALITY inbound.
Where this design is the wrong tool
The README is unusually willing to say when a layer is not worth adding, and that honesty is the most useful thing in it. If a single Hysteria2 inbound is stable on your network and you do not care that AI services see your VPS's native datacenter IP, the README says you can stop there. Tier E is called a bonus. The fixed SOCKS5 for Claude is explicitly optional, and the README states that Claude is not, at the protocol level, required to see a residential IP.
Three limitations are worth stating plainly. First, WARP is not a residential IP and the README says it cannot guarantee any service will accept it; it is an independent Cloudflare exit that happens to be convenient to maintain, nothing more. Second, SOCKS5 is not an encrypted tunnel, as the README notes, so the hop between your VPS and the upstream endpoint is only as private as that link. Third, the fail-closed choice has a cost: the README prefers requests to fail when a fixed upstream is unreachable rather than silently falling back to VPS Direct, because a silent fallback changes the exit IP without the user noticing. That is the right default for a pinned-exit policy, but it means a dead upstream looks like a broken service, not a degraded one, and you need to know which of the three exits failed before you start editing configs.
There is also a scope limit that the repository does not paper over. It is a personal setup. There is no control plane, no user management, no subscription handling and no monitoring. If you need to serve other people, this is the wrong starting point.
How it differs from a single-protocol VLESS or Shadowsocks deployment
The obvious alternative is the common single-inbound setup: one VLESS or Shadowsocks inbound on a VPS, one outbound, everything leaves through the same IP. That approach is simpler and has fewer moving parts, and for a user whose only goal is reaching blocked sites it is usually enough.
The difference in approach is where the decision is made. In a single-inbound setup, the client decides everything: which traffic is proxied and which is not, and all proxied traffic shares one exit. Here, the client makes a coarse decision (direct or proxied) and the server makes the fine one, routing by domain to Direct, WARP or the fixed SOCKS5. That moves credentials off every client machine, which the README lists as a benefit, and it means changing an AI service's exit is a server-side edit rather than a subscription update on each device.
The second difference is the entry layer. Where a single-protocol deployment has one transport, this repository treats Hysteria2 over UDP as the daily path and VLESS with REALITY over TCP as the fallback for networks where UDP is throttled or blocked. The README is clear that this is about reachability, not about the destination's view of you.
A third, quieter difference is the fail-closed default. Most single-outbound setups cannot fail open or closed because there is only one path. Once you pin a service to a specific upstream, you have to choose what happens when that upstream is gone, and this repository chooses failure over silent substitution.
Maintenance, licensing and what the repository does not cover
The last push to the repository was on 2026-09-11, and the repository is not archived. There are no releases, so there is no versioned artifact to upgrade: you track the main branch and the example files, and you re-read them when you change your own configuration. That is a low-maintenance model in one sense, because nothing is installed, and a higher-attention one in another, because upstream projects move. The README pins its own environment in the audit section: Xray 26.3.27, v2rayN 7.24.2, sing-box 1.13.14 for Hysteria2, and the Xray core for REALITY. Those are the versions the author verified against, and they are the numbers to compare with when an example field stops being accepted.
The repository is MIT licensed. That covers the configuration examples and documentation in the repository. It does not cover Xray, sing-box, v2rayN, Hysteria2 or Cloudflare WARP, each of which carries its own licence and terms, and it says nothing about whether your VPS provider permits proxy or VPN use. The README raises that last point as a selection criterion rather than a legal question, and it is the one worth checking before you pay for a machine.
What is missing is equally concrete. The README does not document rollback, there is no troubleshooting section for a WARP reconnect loop, and the fail-closed behaviour is stated as a preference rather than shown in a routing rule in the excerpt. The repository also does not include a client-side example for the fixed SOCKS5 path; the two v2rayN example files cover Hysteria2 and REALITY Vision only.
Editorial conclusion
Adopt this if you already run a VPS for personal use and want a documented way to separate AI service traffic from your VPS native exit, with REALITY kept as an entry fallback rather than a fix for outbound reputation. Do not adopt it if you want a packaged installer, a dashboard or a one-command deploy: the repository is configuration examples plus docs, and the README explicitly says a single Hysteria2 inbound is enough if that is all you need. Before committing, verify three things on your own machine: that UDP 24443 (or UDP 443, if your line handles it) is reachable from your network at peak hours, that your provider permits personal proxy use, and that the placeholder names in examples/xray-server.example.jsonc (YOUR_UUID, YOUR_REALITY_PRIVATE_KEY, YOUR_HY2_PASSWORD) are all replaced before the config is loaded.
Frequently asked questions
What is an edge proxy?
In this repository the term describes a personal proxy endpoint that sits between your devices and the internet, with Hysteria2 as the daily entry and REALITY or Cloudflare Tunnel as fallback entries. The README treats entry and exit as separate concerns, so the edge is where traffic arrives, not where it appears to come from.
Is it better to have the proxy on or off?
The repository does not answer this in general terms. Its client-side rule is that mainland China and private network traffic goes direct while traffic that needs a proxy goes to the VPS, and the server then decides the outbound. For AI services the README argues for routing through WARP or a fixed SOCKS5 rather than the VPS native exit.
Is the WARP exit in personal-edge-proxy safe?
The README states that WARP is not a residential IP and cannot guarantee that any service will accept it, describing it as an independent Cloudflare exit that is convenient to maintain. It also notes that SOCKS5 is not an encrypted tunnel, so the fixed upstream hop has its own exposure.
Community notes