# shadowsocks-windows: a Windows proxy client whose newest release is from 2022 > The PAC logic is the interesting part, down to the attribute tag that keeps a Western company's Chinese CDN off the proxy. Everything around it has drifted: the default branch is v4 while the build badge watches master, the download link leaves for a differently named repository, and the release everyone installs is 4.4.1.0 from February 2022. **shadowsocks/shadowsocks-windows** — GitHub describes it as A C port of shadowsocks. The repository metadata lists C# as its primary language. The metadata lists the NOASSERTION license. This article stays within the project description and details documented in the GitHub repository README. - Repository: https://github.com/shadowsocks/shadowsocks-windows - Stars: 59,550 · Forks: 16,175 - Language: C# - License: NOASSERTION - Published: 2026-08-13 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/shadowsocks-shadowsocks-windows ## The default branch is v4 while the build badge watches master The repository's default branch is `v4`, which is unusual enough to notice before reading anything else. The README then makes three cross-references that assume a different layout. The build status badge points at a branch query for `master`. The GPLv3 licence link resolves to a `blob/master` path. And the release page link does not point into this repository at all, but to `shadowsocks/shadowsocks-csharp`, a separate name for what appears to be the same codebase. The source tree is split the same way. The main project lives in a `shadowsocks-csharp/` directory, the solution file is named `shadowsocks-windows.sln`, and the repository itself is `shadowsocks/shadowsocks-windows`. Three names for one program, and the README mixes them. The consequence is practical rather than cosmetic. A contributor who follows the badge lands on a branch that is not the default, and a user who clicks the download link leaves this repository for one with a different name and cannot tell from the link that anything moved. Neither is fatal, but both mean the documentation cannot be trusted to describe the branch you get by default, and you should check which branch you are actually reading before trusting a procedure in it. ## The newest release is 4.4.1.0 from February 2022 The downloads section tells you to get the latest release from the release page, and the release history is where the dates matter. The three most recent releases are 4.4.1.0 from 2022-02-08, 4.4.0.0 from 2020-12-31 and 4.3.3.0 from 2020-12-07. The last push to the repository was 2025-01-01. So there is a gap of nearly three years between the newest release and the most recent commit, and the version numbers show an irregular cadence before that, with two releases twenty-four days apart at the end of 2020 and then a twenty-one month gap to 4.4.1.0. The repository is not archived, so the code is not frozen, but nothing after February 2022 has been cut as a release. The consequence is that the binary almost everyone installs is not the code at the tip of the branch. If you need a fix that landed after 4.4.1.0, building from source is the only route, and the development section sets out what that costs: Visual Studio 2019 and the .NET Framework 4.8 SDK. Treat the version you install as a fixed artefact from early 2022 and check whether that is acceptable for your environment. ## Editing pac.txt is silently reverted by the next geosite update The user-defined rules section is short and contains a trap. You are told that to define your own PAC rules it is recommended to use the `user-rule.txt` file, and that you can also modify `pac.txt` directly, but that your modifications will not persist after updating geosite from the upstream. That second option is the intuitive one, because `pac.txt` is the generated file and it is right there. It is also the one that gets thrown away. The PAC rules are generated from the geosite database in the v2fly domain-list-community project, and a refresh of that database regenerates the output. The consequence is that a hand-edited rule can work for weeks and then disappear without an error, at the moment someone or something updates the geosite data. A user who has not read this section will reasonably assume their rule broke for a routing reason and go looking in the wrong place. Put custom rules in `user-rule.txt` and treat `pac.txt` as generated output that you never edit, which is what the recommendation amounts to. ## One boolean in gui-config.json decides your whole routing policy The PAC mechanism is the part of this client worth understanding properly. Rules are generated from the geosite database, and two configuration variables hold the policy. `geositeDirectGroups` is initialised with `cn` and `geolocation-!cn@cn`, while `geositeProxiedGroups` is initialised with `geolocation-!cn`. A single property in `gui-config.json`, `geositePreferDirect`, selects between two modes. When it is false, which is the default, PAC runs in whitelist mode: exception rules come from `geositeDirectGroups` and unmatched domains go through the proxy. When it is true, it runs in blacklist mode, with blocking rules from `geositeProxiedGroups` and exception rules from `geositeDirectGroups`, and unmatched domains connect directly. The detail that shows the design was thought through is the `@cn` attribute in `geolocation-!cn@cn`. Since 4.3.0.0 the client defaults to whitelist mode with Chinese domains excluded from the proxy, and the stated purpose is that Chinese domains are connected to directly, including the Chinese CDNs of non-Chinese companies, in both modes. Without that attribute tag, a Western company's Chinese CDN would match the geolocation rule and be sent through the proxy, which is both slow and unnecessary. The consequence for you is that the sensible default is already correct for the case it was written for, and changing `geositePreferDirect` is a decision about unmatched domains only. ## System proxy leaves Windows Store applications going direct Enabling the system proxy from the notification tray covers desktop applications and browsers, with one instruction attached: disable other proxy addons in your browser, or set them to use the system proxy. For manual configuration instead, the README tells you to set a Socks5 or HTTP proxy to `127.0.0.1:1080`, with the port changeable under `Servers -> Edit Servers`. Then there is the exception. For Windows 10 Store applications and related ones, you have to run a command under administrator privilege: ``` netsh winhttp import proxy source=ie ``` This is the gap that catches people out. The WinHTTP proxy setting is separate from the WinINET setting that the system proxy toggle writes, and Store applications use the former. The consequence is that until that command is run, some of your traffic goes straight out while the tray icon shows the proxy as enabled, which looks exactly like a routing bug in the PAC rules. It also requires elevation, so it is a step an automated deployment has to handle separately. ## UDP relay does nothing without SocksCap or ProxyCap Two of the seven advertised features have conditions attached that the feature list does not mention. UDP relay is listed as supported, and the UDP section explains what that costs: to use UDP you need SocksCap or ProxyCap to force the programs you want proxied to be tunnelled over shadowsocks. The client does not capture UDP traffic on its own. Plugins are the second. You set the plugin's path, relative or absolute, on the Edit Servers form, and then there is a note with no elaboration: forward proxy will not be used while a plugin is enabled. Since the plugin is an external program you point at by path, this is a behaviour change you inherit along with the plugin, and nothing in the feature list warns you. The consequence is that the feature list overstates what runs standalone. If UDP matters to you, this is a two-software deployment rather than one, and if you use a plugin you should verify that the local Socks5 or HTTP proxy on port 1080 is still what your applications are configured against, because the client will not be listening in the way it was before. ## Three Appveyor files, three project names, and a GPLv3 dependency list The build configuration is in a visible state of transition. The repository root holds `appveyor.yml`, `appveyor.yml.obsolete` and `appveyor.yml.sample`, and a `.obsolete` file is a thing you do not normally commit. The Appveyor link points at one project path while the build status badge queries a different project identifier, so the two references in the README are not obviously the same project. There is also a `packaging/` directory, an `OPENSSL-GUIDE` file, a `CHANGES` file rather than a changelog, and separate `test/` and `CONTRIBUTING.md` entries. The dependency list is more informative. Nine components are named with their licences, and three of them, Caseless.Fody, Costura.Fody and Fody, come from the Fody organisation, which is the build-time weaving layer. The UI is ReactiveUI.WPF with ReactiveUI.Events.WPF and ReactiveUI.Fody, and the global hotkey support is GlobalHotKey, which is GPLv3, matching the project's own licence stated in the README. The consequence is that the repository layout is mid-migration, and the build status you see in the README is not a reliable answer to whether the default branch builds. If you intend to compile this, expect to sort out the CI configuration first, and note that the stated requirement is Visual Studio 2019 with the .NET Framework 4.8 SDK, plus the Visual C++ 2015 Redistributable for x86 at runtime. ## Conclusion This is a complete Windows proxy client with more configuration surface than most people need, and the routing documentation is precise enough to configure it properly from the README alone. The `geositePreferDirect` switch, the two domain group variables and the `geolocation-!cn@cn` attribute are a well-designed piece of policy configuration, and the multi-instance and hotkey sections show a client built for real desktop use. Three things should stop you treating it as current. The release you are pointed at predates every push to the repository, the README's own cross-references assume a branch that is not the default one, and two advertised features need third-party software to function. Before deploying it, check three things: whether you need UDP and therefore SocksCap or ProxyCap alongside it, whether your rules go in `user-rule.txt` rather than `pac.txt`, and whether the Store-app proxy import has been run, since without it Windows Store applications bypass the proxy entirely. ## FAQ ### Is Shadowsocks a VPN? The documentation never uses the word VPN. It describes a C# port of shadowsocks that configures the Windows system proxy or exposes a local proxy, with PAC and global modes, and tells you to set a Socks5 or HTTP proxy to `127.0.0.1:1080` for manual browser configuration. That is proxy configuration on the local machine rather than a described tunnel. ### Can Shadowsocks be detected? The README does not address detection, obfuscation or traffic fingerprinting at all. What it does document is the local behaviour: the system proxy toggle in the notification tray, PAC and global mode, geosite-driven rules, and a local Socks5 or HTTP listener on port 1080. It also notes that enabling a plugin disables forward proxy. ### Does Shadowsocks hide my IP address? Nothing in the documentation discusses IP addresses or anonymity. The closest it comes is the routing description, where domains in `geositeDirectGroups` are connected to directly and unmatched domains go through the proxy in whitelist mode, and the reverse in blacklist mode. Whether that affects the address a remote service sees is not a question the README takes up. ### Is Shadowsocks safe to use? The project is GPLv3 licensed and its dependencies are listed with licences, including GlobalHotKey under GPLv3. Two operational points are worth knowing: the plugin feature takes a filesystem path to an external program and disables forward proxy while a plugin is enabled, and the command that routes Windows Store applications, `netsh winhttp import proxy source=ie`, must be run under administrator privilege. Requirements are .NET Framework 4.8 or higher and the x86 Visual C++ 2015 Redistributable. ## Sources - [Official README](https://github.com/shadowsocks/shadowsocks-windows#readme) - [Project repository](https://github.com/shadowsocks/shadowsocks-windows) - [Release notes](https://github.com/shadowsocks/shadowsocks-windows/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/shadowsocks-shadowsocks-windows