Furious GUI proxy client: installation and architecture

The desktop proxy problem Furious addresses

Furious targets users who need to operate proxy software through a desktop interface rather than editing configuration files or launching every connection from a terminal. Its stated scope includes Xray-core and Hysteria. Repository topics also identify VLESS, VMess, Reality, SOCKS5, and V2Ray-related use cases, although those topic labels do not document a complete protocol compatibility matrix.

The project is primarily for end users working on a desktop. Its package metadata classifies it for end users, describes the supported operating systems as independent, and requires Python 3.8 or later for package-based installation. Furious is not presented as a server daemon, command-line-only proxy manager, or browser extension. Its main contribution is a graphical control surface around several proxy backends and network-routing helpers.

That scope matters because a proxy GUI has more responsibilities than drawing connection settings. It may need to import configuration, pass settings to an external core, manage system proxy state, request elevated access for TUN, and clean up helper processes after disconnect. The README explicitly discusses a helper that owns TUN-related processes and host-network changes on macOS. This makes Furious a multi-component desktop application rather than a small Python window around one executable.

The project does not target every class of proxy user. Someone managing gateways, server-side routing, or headless containers needs documented process and configuration controls that the README does not provide. Furious instead favors someone who wants a desktop application and expects the application to coordinate the connection lifecycle.

PySide6, proxy cores, and TUN helper boundaries

The visible architecture separates a PySide6 desktop layer from external networking engines. Package metadata includes `PySide6-Essentials` and `PySide6-Addons`, while the GUI entry point is registered as `Furious = Furious.__main__:main`. Traffic handling belongs to the listed proxy packages rather than being implemented entirely inside the Qt interface. The repository layout also includes a top-level `Furious-GUI.py`, `Main.py`, `Resources.qrc`, translations, icons, and a `tests/` directory.

TUN support introduces another process boundary. The README states that on macOS, Furious normally starts a separate helper that owns the selected `tun2socks` or `sing-tun` process and its host-network changes. Disconnecting uses the same helper for cleanup. A desktop application therefore does not have to perform every host-network mutation inside its GUI process.

The macOS documentation also distinguishes application TUN from proxy-core native TUN. Furious requests administrator authorization when an application TUN connection starts. Native TUN retains the privilege requirements of the selected backend. The README does not define those native requirements or document equivalent privilege handling for Windows and Linux, so behavior on those platforms must be verified separately.

Several supporting dependencies suggest that the application handles more than connection fields. `ujson`, `pybase64`, `segno`, `icmplib`, `mss`, `zxing-cpp`, and `pillow` cover JSON processing, Base64 operations, QR generation, network utilities, screen capture, barcode decoding, and images. The README does not map each package to a particular screen, import path, or diagnostic feature. They show a broader desktop utility layer, not a minimal proxy switcher.

Installing Furious and reaching its first real use

For most users, the README recommends downloading a packaged build from GitHub Releases. That path is the documented choice for users who do not want to assemble the Python and native dependency set themselves. Windows users can instead install the published application through WinGet:

winget install --id=LorenEteval.Furious -e

After WinGet completes, the packaged Furious application should be available to launch. The README does not state its installation path or describe the first screen, so those details should come from the installed application rather than assumptions about the Python entry point.

Users with a suitable Python environment can install the PyPI package:

pip install Furious-GUI

The package requires Python 3.8 or later. Its dependencies include PySide6 components, proxy cores, TUN helpers, and platform-specific integration packages. A fresh package installation can therefore involve native components and more than a single pure-Python dependency.

The README sends users to the Quick Start wiki page for launch and compatibility details. It does not provide a subscription command, server address template, configuration import command, or exact first-click sequence. A real first use starts with the packaged application or the installed GUI entry point and then follows the Quick Start workflow. If startup or connection fails, the repository directs users to its Troubleshooting and Diagnostics wiki page instead of documenting a local recovery command.

Cross-platform dependencies and packaging costs

Furious is described as cross-platform, but its dependency set changes by operating system. On Windows, `requirements.txt` includes `sysproxy` and `win32session`. On macOS, it includes `darkdetect[macos-listener]`, `pyobjc-core`, and `pyobjc-framework-Cocoa`. Other systems omit those packages. This conditional approach fits desktop integration, but an installation can succeed on one platform and fail on another because of native wheels, privileges, or operating-system compatibility.

The fixed dependency `sing-tun==0.9.7.dev2` is an explicit development-version pin. Such a pin can make the current dependency set reproducible, but it also creates a clear upgrade boundary. Changing it requires checking compatibility with the TUN lifecycle, helper ownership, and supported platforms. Neither the README nor `requirements.txt` explains why this version was selected or how often it is updated.

There are also two installation paths with different dependency behavior. GitHub Releases contain packaged builds, while PyPI distributes `Furious-GUI` and registers the `Furious` GUI script. A user may therefore encounter different package contents or dependency resolution depending on which route is selected. `pyproject.toml` uses `setuptools>=61` as its build requirement and packages the `Furious` and `Furious.*` modules. The README points to the Install from PyPI wiki page for compatibility and launch information, which is the relevant place to check before relying on the package route.

TUN privileges and process cleanup constrain deployment

Furious is the wrong operating model for a host without a desktop session or for a deployment whose main requirement is a minimal terminal workflow. Its declared entry point is a GUI script, and its documentation centers on PySide6, desktop proxy cores, system proxy integration, and TUN helpers. The repository does not document a daemon mode, service unit, remote administration interface, or headless configuration command.

TUN adds a separate operational risk. On macOS, starting application TUN requests administrator authorization. Proxy-core native TUN retains backend-specific privilege requirements, which the README leaves unspecified. A deployment without suitable privileges may reach an authorization failure before the connection becomes usable.

The helper-based macOS design also makes process ownership relevant during disconnect. The same helper owns the selected `tun2socks` or `sing-tun` process and performs cleanup. The README does not describe recovery after the helper is forcibly terminated, behavior during an application crash, or how to diagnose a stale host-network change. Those cases belong in the Troubleshooting and Diagnostics wiki if documented there, but they should not be assumed from the normal disconnect description.

Protocol selection is another verification point. Repository topics mention VLESS, VMess, Reality, SOCKS5, and V2Ray, but the project description only confirms support for Xray-core and Hysteria. Users with strict transport or authentication requirements should verify the selected core and configuration against the Quick Start rather than treating topic labels as a complete feature list.

Furious versus direct Xray-core or Hysteria operation

The practical alternative is to operate Xray-core or Hysteria directly. Both approaches can use the same networking backends, but they present different control surfaces. Direct core operation keeps the networking engine in the foreground or under an external process manager and relies on the configuration and lifecycle controls supplied by that backend. Furious adds a PySide6 interface and coordinates proxy cores, TUN helpers, desktop integration, and cleanup.

That layer is useful when graphical configuration is the priority and the user does not want to manage the selected core directly. It is less attractive for a server engineer who already has process supervision and wants a narrow deployment without GUI dependencies. Installing Furious brings in PySide6 components, image and scanning utilities, TUN packages, and platform integration code even though actual traffic handling is delegated to networking backends.

The choice is therefore about workflow rather than a claim about proxy performance. Furious is relevant when desktop management and its documented TUN lifecycle matter. Direct core use is the clearer alternative for headless execution, explicit process ownership, or backend-native configuration. The repository provides no benchmark comparing startup time, memory consumption, throughput, or connection recovery, so none of those differences should be inferred.

Maintenance, licensing, and release upgrade boundaries

The repository is not archived. Its last push was on 2026-10-15. Listed releases include 0.8.2 on 2026-09-19, 0.8.1 on 2026-09-09, and 0.8.0 on 2026-08-31. These dates show recent repository and release activity, but they do not establish that every operating system or dependency combination is compatible.

The project metadata declares `GPL-3.0-or-later`, while the README describes the license as GPL v3.0. That distinction can matter when redistributing modified versions or incorporating the project into another product. The exact obligations depend on the applicable license text and distribution context, so this article does not provide legal advice. The repository includes `LICENSE` and `LICENSE.rtf`, and `setup.py` excludes Markdown files under the packaged `Data` directory.

An upgrade has several concrete checkpoints. A user may choose a GitHub Release build or install `Furious-GUI` through Python, and those paths can resolve different environments. The project depends on proxy-core packages, TUN helpers, and an exact `sing-tun` development-version pin. On macOS, application TUN also requires administrator authorization, while native backend TUN retains its own requirements. Before changing versions, check `pyproject.toml`, `requirements.txt`, the selected release, and the Troubleshooting and Diagnostics wiki page for changes involving those components.

Editorial conclusion

Furious is appropriate for desktop users who specifically want a PySide6 interface over Xray-core or Hysteria and are prepared to troubleshoot proxy-core and TUN dependencies. It is a poor fit for headless servers or users seeking a minimal CLI-only client. Before adoption, verify the selected installation path on the target operating system, then confirm that the required TUN privileges and disconnect behavior work there. For a package-based Furious installation, the first operational check should be whether the selected proxy-core connection starts and disconnects cleanly through the documented Quick Start workflow.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. LorenEteval/Furious on GitHub
4. README
5. Releases