[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-2080":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":17,"stars7d":18,"stars30d":19,"stars90d":16,"forks30d":16,"starsTrendScore":20,"compositeScore":21,"rankGlobal":10,"rankLanguage":10,"license":22,"archived":23,"fork":23,"defaultBranch":24,"hasWiki":25,"hasPages":23,"topics":26,"createdAt":10,"pushedAt":10,"updatedAt":39,"readmeContent":40,"aiSummary":41,"trendingCount":16,"starSnapshotCount":16,"syncStatus":15,"lastSyncTime":42,"discoverSource":43},2080,"SwizGuard","0xXyc\u002FSwizGuard","0xXyc","A self-hosted \"Stealth VPN\" implementation, forked from xray-core and WireGuard. It makes your traffic look like normal TLS traffic but little does your ISP know there is an entire encrypted WireGuard tunnel in there... ","",null,"Shell",167,16,1,2,0,9,15,37,27,3.69,"MIT License",false,"main",true,[27,28,29,30,31,32,33,34,35,36,37,38],"censorship-circumvention","censorship-resistance","obfuscation","privacy","selfhost","sing-box","stealth","tls","vless","vpn","vps","wireguard","2026-06-12 02:00:36","\u003Cp align=\"center\">\n  \u003Cimg src=\"docs\u002Fimages\u002Fswizguard-logo.png\" alt=\"SwizGuard — fight back for privacy that's yours\" width=\"600\">\n\u003C\u002Fp>\n\n# SwizGuard\n\nSelf-hosted stealth VPN. Your traffic looks like normal HTTPS to a major website. Your ISP has no idea you're tunneling anything. Works on Mac, Linux, Windows, iPhone, and Android. One command deploys the server, another spits out configs for every device you own.\n\n## Why I built this\n\nI travel a lot. Hotel Wi-Fi, sketchy airport networks, countries where half the internet is blocked or actively monitored. I got tired of running into the same three problems over and over.\n\nFirst one: regular VPNs get blocked. Not just in the obvious places like China or Iran. Corporate networks, coffee shops with weird filtering, hotel Wi-Fi that throws up captive portals and then flags WireGuard traffic. You fire up NordVPN and it just... doesn't work. Or it works for ten minutes and then the network figures out what you're doing and cuts you off.\n\nSecond one: consumer VPNs want you to trust them. Nord, Express, Mullvad, whoever. They all promise \"no logs\" but you're taking their word for it. Their entire business model requires you to believe them about something you can't verify. I'm not comfortable handing my traffic to a company I can't audit, especially when that company owns the exit point for everything I do online.\n\nThird one: my family. My partner, my parents, people who aren't going to SSH into a VPS and fiddle with configs. I wanted something I could set up once and then just hand them a file that makes their phone work safely anywhere. No monthly subscription, no app full of ads, no trusting some random Panama corporation with their browsing history.\n\nThe existing options all suck in different ways. WireGuard alone is fast and clean but trivially detectable — every modern DPI system can fingerprint it in milliseconds. OpenVPN is slower AND detectable. Commercial VPNs are blocked and require trust. Tor is anonymous but too slow for daily use and not really designed for \"just let me check email on hotel Wi-Fi.\"\n\nSo I built what I actually wanted. Something that:\n\n- Looks like HTTPS to microsoft.com to anyone watching, because that's literally what the bytes on the wire say\n- Runs on my own $5 VPS, so I'm the only one with access to the keys and the logs (the logs don't exist by default)\n- Works on iPhone with one file import, not \"sideload this custom IPA and jailbreak your phone\"\n- Deploys with one command so I can stand up a new server in 60 seconds if I need to move jurisdictions\n- Doesn't ask my family to understand VLESS or REALITY or any of the underlying protocols — they just get a file, import it, tap connect\n\nSwizGuard is the result. I use it every day on my Mac and my iPhone. My partner uses it. I've set it up for family members I trust but would never trust to maintain it themselves. If you have similar reasons — you travel, you don't trust consumer VPNs, you want actual privacy without the BS — this is for you.\n\n## What it actually does\n\nA normal VPN shows up on the wire as \"this is a VPN.\" Wireshark can see it, DPI can fingerprint it, corporate firewalls can block it. WireGuard's handshake pattern is unique. OpenVPN's TLS handshake doesn't match real browsers. Even Nord and Express use IP ranges that every firewall vendor has already flagged.\n\nSwizGuard is different. It wraps your WireGuard tunnel inside VLESS+REALITY with Vision flow, which is a protocol stack designed to be cryptographically indistinguishable from a real HTTPS connection to a real website. When someone probes your server, they get a real Microsoft certificate — because REALITY proxies the handshake to the actual microsoft.com edge server and returns whatever comes back. There's nothing fake to detect.\n\nWhat your ISP sees:\n```\nyour device → TLS 1.3 → www.microsoft.com\n```\n\nWhat's actually happening:\n```\nyour device → Xray\u002Fsing-box (WireGuard → VLESS → REALITY → Vision) → your VPS → real internet\n```\n\nThree layers of encryption. Zero signal that a VPN exists. No third party in the trust chain except your own VPS provider.\n\n## What this looks like on the wire\n\nThis is the part that matters. Here's what an observer (your ISP, a corporate firewall, a censoring government) actually sees in Wireshark.\n\n### Plain WireGuard\n\n![Raw WireGuard in Wireshark](docs\u002Fimages\u002Fraw-wireguard-wireshark.png)\n\nEvery packet is labeled `WireGuard`. Wireshark identifies the protocol immediately because the handshake pattern is unique and the transport headers are distinctive. Any DPI system, any modern firewall, any network operator with basic tooling can flag these packets in milliseconds. They don't need to decrypt anything — the protocol identification IS the fingerprint.\n\nThe \"Info\" column even shows packet types: `Transport Data, receiver=0x..., counter=...`. That's WireGuard's internal session structure leaking out. To a censor, this is a screaming neon sign that says \"VPN here, please block me.\"\n\n### SwizGuard\n\n![SwizGuard traffic in Wireshark](docs\u002Fimages\u002Fswizguard-wireshark-tls.png)\n\nEvery packet is labeled `TLSv1.2` or `TCP`, port 443, \"Application Data\". This is what HTTPS to any normal website looks like in Wireshark. Same shape as Safari loading microsoft.com, or Mail checking iCloud, or your phone updating an app.\n\nThere is no `WireGuard` label anywhere because WireGuard is happening **inside** the encrypted TLS session. Wireshark doesn't know it's there. DPI doesn't know it's there. Your ISP doesn't know it's there. The fingerprint that gives away plain WireGuard isn't visible because it's wrapped inside REALITY's outer TLS layer, and Vision flow pads the inner handshake to defeat the TLS-in-TLS detection technique that catches naive nested TLS proxies.\n\n### Why this matters\n\nIn a normal day on a normal home network in the US, the difference between these two captures is mostly philosophical — your ISP isn't actively blocking VPNs, so plain WireGuard works fine. But the moment you step outside that environment, the difference becomes the difference between \"I have internet\" and \"I don't.\"\n\n- **Hotel and airport Wi-Fi.** Many of them block known VPN protocols to enforce captive portal terms or to throttle \"non-business\" traffic. Plain WireGuard gets dropped. SwizGuard goes straight through because it's just HTTPS.\n- **Corporate networks.** Most enterprise firewalls are configured to identify and block VPNs by default. Plain WireGuard fails. SwizGuard looks like browsing microsoft.com — and ironically, in a Microsoft 365 environment, that traffic pattern is so common it's invisible.\n- **State censorship.** China's GFW, Russia's TSPU, Iran's filtering — all use deep packet inspection that fingerprints VPN protocols. Plain WireGuard is dead the moment you cross the border. SwizGuard works because nothing in the wire format gives away the VPN.\n- **Surveillance environments.** Even when you're not blocked, the simple fact that \"Jake is using a VPN\" is metadata. Your ISP can sell that, log it, hand it over with a subpoena, or use it as a flag in an automated system. With SwizGuard, that metadata doesn't exist — there's nothing to tell your ISP that anything unusual is happening.\n\nThe Wireshark difference is the entire reason SwizGuard exists. Plain WireGuard says \"I am a VPN, please make decisions based on that.\" SwizGuard says \"I am someone reading microsoft.com, please ignore me.\"\n\n## How it holds up\n\nI tested this in real conditions. My own daily use on a VPS I rent from a cheap provider, running on my Mac with system proxy enabled and my iPhone using sing-box via SFI. Here's what I can verify:\n\n- My ISP sees HTTPS traffic to microsoft.com. That's it. I checked with Wireshark from a separate machine on the same LAN.\n- Active probing my VPS returns Microsoft's real certificate served through Akamai's CDN. I confirmed this by running `curl --resolve www.microsoft.com:443:MY_VPS_IP https:\u002F\u002Fwww.microsoft.com` and getting a real HTTP\u002F2 200 back from AkamaiGHost with a valid DigiCert cert.\n- The WireGuard layer is running underneath. I confirmed this by SSH'ing to the VPS and running `sudo wg show wg1`, which shows my clients connecting with `endpoint: 127.0.0.1:xxxxx` — loopback, meaning the WG packets are arriving via the REALITY unwrap path.\n- Firefox throws a \"cert doesn't match IP\" warning if I visit my VPS IP directly. That's the same warning you'd get hitting any Akamai edge server by IP — it's a feature, not a bug.\n\nNone of this is me trusting someone else's marketing copy. It's stuff I can point Wireshark at and see for myself.\n\n## Features\n\n- **Full WireGuard + VLESS + REALITY + Vision chain on every platform** — same architecture on desktop and mobile, generated from one command\n- **Vision flow (`xtls-rprx-vision`)** — closes the TLS-in-TLS fingerprint that catches plain VLESS+REALITY\n- **Single process on the client** — no wg-quick, no kernel tunnel, no sudo to start the tunnel\n- **Desktop uses Xray-core** with chained outbounds via `sockopt.dialerProxy`\n- **Mobile uses sing-box via SFI\u002FSFA** with chained endpoints via `detour`\n- **Zero access logs on the server** — the VPS doesn't record where you go\n- **Pairs with VPS hardening scripts** — auto-detects UFW and only opens port 443\n- **microsoft.com is the default camouflage** — Xray specifically warns against apple.com and icloud.com, so I avoid those\n- **Works on a $5 VPS** — I run mine on one of the cheapest tiers, it keeps up fine\n\n## Requirements\n\n### Server\n- Debian 12 or 13, or Ubuntu 22.04 or 24.04 (amd64 or arm64)\n- Root access\n- Any cheap VPS — Vultr, Linode, Hetzner, DigitalOcean, whatever\n- Port 443\u002Ftcp open to the internet\n\n### Desktop (macOS \u002F Linux \u002F Windows)\n- `xray-core` v1.8 or newer, v26.x recommended\n- macOS: `brew install xray`\n- Linux: grab a binary from `github.com\u002FXTLS\u002FXray-core\u002Freleases`\n- Windows: same releases page, add `xray.exe` to PATH\n\n### iPhone\n- iOS 15 or later\n- **SFI (Sing-Box For iOS)** from the App Store\n- If the App Store version is stale, the TestFlight build usually has the latest sing-box core\n\n### Android\n- **SFA (Sing-Box For Android)** from Play Store, or\n- **v2rayNG** if you prefer Xray natively\n\n## Quick start\n\n### Step 1 — set up the server\n\nOn a fresh VPS, ideally after running a hardening script first (see below):\n\n```bash\ngit clone https:\u002F\u002Fgithub.com\u002FYOUR_USER\u002Fswizguard.git\ncd swizguard\nsudo .\u002Fswizguard setup\n```\n\nThat's it. Sixty seconds later you have:\n- Xray-core installed and running on port 443 with VLESS + REALITY + Vision\n- A WireGuard server on localhost:51821 (never exposed externally)\n- Camouflage set to `www.microsoft.com`\n- REALITY keys, WireGuard keys, client UUID, short ID — all generated and saved\n- Systemd services enabled so everything survives a reboot\n\n### Step 2 — add clients for every device you own\n\n```bash\nsudo .\u002Fswizguard add macbook\nsudo .\u002Fswizguard add iphone\nsudo .\u002Fswizguard add partner-laptop\nsudo .\u002Fswizguard add mom-phone\n```\n\nEach client gets a package containing:\n- `xray-client.json` — for desktop full chain\n- `singbox-client.json` — for iOS SFI or Android SFA full chain\n- `connect-\u003Cname>.sh` — launcher for desktop\n- A VLESS share link and QR code (fallback for clients that can't import raw JSON)\n\n### Step 3 — connect your desktop\n\n```bash\n# On your Mac or Linux box\nscp -P 13337 -i YOUR_KEY YOUR_USER@YOUR_VPS:\u002Fetc\u002Fswizguard\u002Fclients\u002Fmacbook .\u002F\ncd macbook\nbash connect-macbook.sh\n```\n\nTo verify:\n```bash\ncurl --socks5 127.0.0.1:10808 -4 ifconfig.me\n```\n\nThat should return your VPS IP. If you want all Mac traffic to route through the tunnel (not just apps you configure manually):\n\n```bash\nbash connect-macbook.sh enable-system-proxy\n```\n\n### Step 4 — connect your iPhone (full chain)\n\n1. Install **SFI (Sing-Box For iOS)** from the App Store\n2. Get `singbox-client.json` from the VPS onto your iPhone. Easiest way: SCP to your Mac, AirDrop to iPhone, save to Files\n3. In SFI: Profiles tab → `+` → Local → pick the JSON file\n4. Dashboard tab → select the new profile → Start → Allow VPN permission\n5. Open Safari and visit `ifconfig.me`. You should see your VPS IP\n\n### Step 5 — connect Android\n\nSame file-based import, different app. Either SFA (sing-box native) or v2rayNG (Xray native). Both support the full chain.\n\n## Commands\n\n| Command | What it does |\n|---|---|\n| `.\u002Fswizguard setup` | Fresh install on a new VPS |\n| `.\u002Fswizguard add \u003Cname>` | Generate a new client package |\n| `.\u002Fswizguard regen \u003Cname>` | Regenerate configs for an existing client (after server changes) |\n| `.\u002Fswizguard share \u003Cname>` | Print the QR code and VLESS link for an existing client |\n| `.\u002Fswizguard list` | List all clients |\n| `.\u002Fswizguard remove \u003Cname>` | Revoke a client |\n| `.\u002Fswizguard status` | Server health, connected peers |\n| `.\u002Fswizguard upgrade-vision` | Enable Vision flow on an older deployment |\n| `.\u002Fswizguard rekey` | Rotate REALITY keys (breaks all existing clients until regen) |\n| `.\u002Fswizguard nuke` | Uninstall everything |\n| `.\u002Fswizguard help` | Show help |\n\n## Recommended deployment order\n\nI pair SwizGuard with my [VPS-Lock-Figuration](https:\u002F\u002Fgithub.com\u002F0xXyc\u002FVPS-Lock-Figuration) script on every box. That hardening script is what I run first on any fresh VPS — it creates a non-root user, enforces SSH key auth only, moves SSH to a custom port, enables UFW with restrictive defaults, installs fail2ban, and turns on unattended security upgrades. Run that first before you install anything else.\n\nThen deploy SwizGuard as the non-root user with sudo. It detects UFW automatically and opens only port 443. The two scripts compose cleanly — Lock-Figuration sets the baseline, SwizGuard adds the stealth VPN on top. Total time from fresh VPS to working tunnel is under five minutes.\n\n## Verifying the camouflage yourself\n\nDon't take my word for any of this. Test it. From a machine that's NOT connected to the tunnel:\n\n```bash\ncurl -I --resolve www.microsoft.com:443:YOUR_VPS_IP https:\u002F\u002Fwww.microsoft.com\n```\n\nYou should see something like:\n```\nHTTP\u002F2 200\nserver: AkamaiGHost\ncontent-type: text\u002Fhtml\n```\n\nThat response is coming from real Akamai infrastructure proxied through your VPS by REALITY. The certificate in the TLS handshake is a real DigiCert-signed cert for `*.microsoft.com`. Your server is behaving exactly like a Microsoft edge node because, mechanically, that's what REALITY makes it do when probed.\n\nIf you visit `https:\u002F\u002FYOUR_VPS_IP` directly in Firefox, you'll get a \"cert doesn't match IP\" warning. That's expected. Real Microsoft cert, wrong hostname — same behavior you'd get hitting any Akamai edge by IP address. Cert matching is domain-based, not IP-based. Firefox is confirming the camouflage.\n\n## Documentation\n\n- [How It Works](docs\u002Fhow-it-works.md) — technical deep dive on the chain, REALITY, Vision flow, threat model\n- [Setup Guide](docs\u002Fsetup-guide.md) — step-by-step server deployment, client generation, mobile setup\n- [Troubleshooting](docs\u002Ftroubleshooting.md) — every weird issue I hit during development, and how I fixed it\n\n## What this protects against\n\n- Passive inspection by your ISP, network operators, corporate firewalls\n- Active scanning and probing of your server\n- TLS-in-TLS fingerprinting (the technique GFW uses to catch plain VLESS+REALITY)\n- DPI-based VPN detection\n- Commercial VPN blocklists\n- Consumer firewalls at hotels, airports, coffee shops, schools\n\n## What it doesn't protect against\n\nI'm going to be honest about this because too many VPN tools oversell their own capabilities.\n\n- **Global passive adversaries doing end-to-end timing correlation.** If a nation-state actor can see both your ISP traffic AND your VPS's upstream provider, they can correlate packet timing and figure out your destinations. No low-latency VPN defeats this. Tor is the answer for that threat model.\n- **VPS provider compromise or legal compulsion.** If your VPS provider is subpoenaed or compromised, the attacker gets root on the box. Pick your provider and jurisdiction based on your actual threat model. Pay with Monero if you want to decouple your identity from the server.\n- **Endpoint compromise.** Malware on your phone or laptop reads your traffic before encryption. No VPN helps. Keep your devices clean.\n- **Behavioral deanonymization.** If you log into Google with your real name while connected, Google knows it's you. The VPN hides your network location, not your identity. These are two different things.\n\nSee [docs\u002Fhow-it-works.md](docs\u002Fhow-it-works.md) for the full threat model.\n\n## Credits\n\nThis tool stands on a lot of other people's work. The protocols and primitives are all upstream:\n\n- **[Xray-core \u002F XTLS team](https:\u002F\u002Fgithub.com\u002FXTLS\u002FXray-core)** — REALITY protocol, Vision flow, the WireGuard outbound, and the `sockopt.dialerProxy` chaining pattern that makes the whole thing possible\n- **[sing-box \u002F SagerNet](https:\u002F\u002Fgithub.com\u002FSagerNet\u002Fsing-box)** — sing-box itself, the `wireguard` endpoint, and the `detour` field for chaining on mobile\n- **[WireGuard](https:\u002F\u002Fwww.wireguard.com\u002F)** — the VPN protocol that does the actual inner encryption\n- **[Xray's Warp-over-proxy guide](https:\u002F\u002Fxtls.github.io\u002Fen\u002Fdocument\u002Flevel-2\u002Fwarp.html)** — the canonical reference for how `dialerProxy` chaining is supposed to work\n\nSwizGuard is the automation and packaging layer. It stitches these tools together into something deployable, handles the key generation and config templating, generates matching Xray and sing-box configs from one source of truth, and gives you management commands so you don't have to hand-edit JSON every time you add a device. Everything cryptographic underneath is someone else's work that I'm using as a library.\n\n## License\n\nMIT. See [LICENSE](LICENSE).\n\n## Disclaimer\n\nSwizGuard is a privacy and censorship-resistance tool. Use it legally in your jurisdiction. I make no warranty and accept no liability for misuse. I built it because I needed it for my own travel and privacy, and I'm releasing it publicly because other people probably need something similar. See [DISCLAIMER.md](DISCLAIMER.md) for the full disclaimer.\n","SwizGuard 是一个自托管的隐身VPN实现，基于xray-core和WireGuard。它使你的网络流量看起来像是访问知名网站的正常HTTPS流量，但实际上内部是一个完全加密的WireGuard隧道。该项目支持Mac、Linux、Windows、iPhone和Android设备，并且只需一条命令即可部署服务器，另一条命令则可以为所有设备生成配置文件。SwizGuard特别适合在旅行时使用不安全的公共Wi-Fi（如酒店或机场），以及在互联网被封锁或监控的国家和地区。通过将流量伪装成普通HTTPS请求，SwizGuard能够绕过大多数网络审查与监控系统，同时保持用户数据的安全性和隐私性。","2026-06-11 02:47:58","CREATED_QUERY"]