Does Holy Unblocker Work on Mobile? Android and iPhone Guide
HUHoly Unblocker What It IsHow It WorksFeaturesSupported SitesDownloadGuideFAQ Get it on GitHub Home / Guide / Holy Unblocker on Mobile GUIDE · MOBILE Does Holy Unblocker Work on Mobile? Android and iPhone Guide What affects mobile compatibility, how to try it on Android and iPhone, and what to check when it fails. Updated 202610 min readMobile Mobile compatibility for Holy Unblocker Two phone outlines, Android and iPhone, each connect through a browser to a hosted instance and then to a destination website, with a note that browser, engine, server and site all influence the result AndroidChromium · Firefox iPhoneSafari · others Hosted instanceengine · transport · server Websitescripts · security Browser, engine, server and website all affect the result. Mobile support depends on the version. Test simple pages first. Mobile access is a chain. Any link in it can be the one that fails. Many people browse mostly on a phone, so it’s natural to ask whether Holy Unblocker works on one. The short answer: it is a browser-based proxy project, so mobile access may be possible through a compatible browser, but compatibility and performance aren’t guaranteed on every Android phone, iPhone or website. Its development continued as InvisiProxy LTS (see Holy Unblocker vs InvisiProxy), which uses browser-based proxy technologies including Scramjet and Ultraviolet plus supporting transports. These have different browser requirements, and the project’s own development notes identify mobile support as an area needing improvement. Does It Work on Mobile Phones? Holy Unblocker is a web-based service rather than an app you install from a store, so you can potentially use a compatible hosted instance in a mobile browser. But the homepage opening doesn’t mean everything works. The engine must support the browser, the website must be compatible with the proxy, and the server must be configured correctly. Mobile compatibility can depend on: The browser and its version, and the mobile operating system The proxy engine the application uses (see Holy Unblocker vs Ultraviolet) Support for service workers and other browser features The connection between the browser and the proxy server The destination site’s scripts, security settings and network requirements Version matters. The InvisiProxy LTS repository lists mobile-support improvements among its development tasks, so treat mobile compatibility as dependent on the particular version rather than assuming universal support. Does It Work on Android? It may, through a compatible browser and hosted instance. Android offers several Chromium-based browsers, but shared foundations don’t guarantee identical behavior for every proxy feature. How to try it on Android Open a modern, updated browser on your phone. Go to a legitimate instance that you trust and are authorized to use. Wait for the homepage and interface to load completely. Enter the address of a supported website in the proxy’s input field. If it fails, test a simple page to see whether the issue affects the whole proxy or one destination. If the app offers a choice of engines or transports, try another supported option. The interface may differ between older Holy Unblocker deployments and current InvisiProxy LTS versions. Which Android browsers to try Chrome for Android: a reasonable first test because it is widely used and supports service workers. Engine compatibility still needs checking. Microsoft Edge for Android: also Chromium-based and may work, but isn’t guaranteed to behave identically to Chrome. Firefox for Android: uses a different engine. Compatibility can vary, and the project’s development notes identify Firefox support as needing work. Other browsers: results depend on their engine, privacy settings, service-worker implementation and version. If one browser fails, compare another before concluding the whole service is down. Does It Work on iPhone? It may be accessible through Safari or another browser, but support for individual engines and features can be more limited than people expect. Browser behavior on iOS is governed by Apple’s platform rules, so even browsers with different interfaces may share important limitations. How to try it on an iPhone Update iOS to a version supported by your device. Open Safari or another browser on your iPhone. Visit a trusted, authorized instance. Wait for the interface to load, then enter a supported website’s address. Test a simple webpage first. If it fails, try a different destination and check whether only one website is affected. If the homepage loads but the proxied site doesn’t, the cause may be the engine, a missing resource or an unsupported feature, not basic access. Why might it be less reliable on iPhone? The engine may rely on browser behavior that differs across platforms A website may need unsupported network or browser features The mobile interface may have layout or navigation bugs A connection may drop when you switch apps or networks Privacy controls may affect storage, cookies or service-worker behavior The hosted instance may be outdated or having problems These are possible causes, not proof it can’t work on iPhones. Assess compatibility against the specific version, browser and destination. Android vs iPhone Neither platform is universally better. The result depends on the browser, engine, OS version and website. Factor Android iPhone Access through a browser Potentially supported Potentially supported Browser choice Several engines and variants Subject to iOS platform constraints Service workers Depends on browser and version Depends on browser and iOS version Engine compatibility Varies by engine and browser Varies by engine and browser Touch usability Depends on the site’s mobile layout Depends on the site’s mobile layout Website compatibility Not guaranteed Not guaranteed Performance Device, network, server, website Device, network, server, website If you have both devices, test the same instance and destination on each. That shows whether a problem is specific to the device, browser or proxy service. How to Use It in a Mobile Browser With a trusted instance that supports your browser, the process is much like desktop. Step 1, open the proxy site. Use official project information to find a legitimate instance, and beware of unofficial copies that imitate the interface or ask for unnecessary personal information. Step 2, let the interface finish loading. It may need to load
Holy Unblocker vs Ultraviolet: Key Differences, Features, and Which Is Better?
HUHoly Unblocker What It IsHow It WorksFeaturesSupported SitesDownloadGuideFAQ Get it on GitHub Home / Guide / Holy Unblocker vs Ultraviolet GUIDE · COMPARISON Holy Unblocker vs Ultraviolet: Key Differences, Features and Which Is Better? One is a complete proxy project, the other is an engine that can power one. Here is how they differ and when each matters. Updated 202612 min readComparison Holy Unblocker compared with Ultraviolet Holy Unblocker, a complete application containing an interface, server services, and proxy engines, is shown on the left. Ultraviolet, a single service-worker based proxy engine and one of those engines, sits on the right, with Scramjet marked as its successor Holy Unblocker / InvisiProxy LTS complete application Web interface Server services Ultravioletengine Scramjetengine TransportsWisp · Bare-Mux Ultraviolet proxy engineservice-worker interceptionSuccessor: Scramjet An application and an engine are different things. Ultraviolet is one of the engines Holy Unblocker has used. They are related, not interchangeable. When researching browser-based proxies, you will meet both Holy Unblocker and Ultraviolet. They are closely related but not the same thing. Holy Unblocker LTS was a web proxy project that brought together a website interface, server-side services and several proxy technologies, and its development continued as InvisiProxy LTS (see Holy Unblocker vs InvisiProxy). Ultraviolet is a proxy engine originally developed by TitaniumNetwork that uses service workers to intercept and process browser requests. The confusion exists because Holy Unblocker has used Ultraviolet as one of its proxy options. The newer InvisiProxy LTS also includes Scramjet, which its current website recommends as the primary option, with Ultraviolet as a fallback. What Is Holy Unblocker? Holy Unblocker was a browser-based web proxy that let users reach supported websites through a web interface, with no traditional desktop proxy app. It combined a user-facing interface with components for processing requests, managing browser-side functionality and talking to proxy services. Depending on the version, those included Ultraviolet, Scramjet, Rammerhead and supporting transport technologies. Because development continued as InvisiProxy LTS, older Holy Unblocker documentation and newer InvisiProxy documentation may describe different versions, configurations or recommendations. A browser-based interface for supported websites Integration with engines such as Ultraviolet and Scramjet, depending on version Supporting services and transport options Configuration options for self-hosting and deployment Compatibility that varies by engine, browser and destination site Holy Unblocker is a broader proxy project, not simply another name for Ultraviolet. What Is Ultraviolet? Ultraviolet is an open-source proxy engine from TitaniumNetwork. It processes website requests inside a controlled browser environment using a service worker, a browser feature that can intercept certain network requests for a site. It uses this to rewrite website resources so supported content works through its proxy. It also supports configurable URL encoding, request processing and integration with supporting transports, though compatibility is not universal. An open-source proxy engine Service-worker-based request interception Integration with supporting libraries and transport components A codebase developers can study and adapt under its license Maintenance matters. The official Ultraviolet repository states that the project is no longer actively maintained as it once was and names Scramjet as its successor. It remains useful as a reference for existing installations, but check the latest repository information before choosing it for a new deployment. Quick Comparison Feature Holy Unblocker / InvisiProxy LTS Ultraviolet Type Complete web proxy project Proxy engine Main purpose Provides a web interface and integrates proxy components Processes supported website requests through a browser-based proxy User interface Includes a website interface Usually supplied by a separate application Service workers Depends on the integrated engine and version Uses service workers Other engines May integrate several One specific engine Self-hosting Deploy the overall project Integrate into a compatible application Configuration Application-level and engine-specific settings Engine-specific settings and supporting components Maintenance Depends on the current InvisiProxy LTS release Repository names Scramjet as its successor Best use case An integrated proxy project Maintaining or studying an Ultraviolet-based setup The key difference is scope: Holy Unblocker is the overall application, while Ultraviolet is one of the technologies that can power a proxy application. They are not direct substitutes in every situation. 1. Architecture Holy Unblocker combined a user-facing website with server-side services, browser-side code and proxy engines. A request typically meant the user entering an address, the application using an engine, and the engine processing the needed resources (see how Holy Unblocker works). Exact architecture varies by version, so older installs may differ from current InvisiProxy LTS releases. Ultraviolet focuses on the proxying itself. Its service worker intercepts supported browser requests and processes them. The application that integrates it supplies the interface, serves the assets, configures supporting services and makes the parts work together. That separation lets developers use Ultraviolet in different applications. To use a ready-made project, the complete application structure matters. To build your own, an engine may offer more flexibility, though you must integrate and maintain it. Neither approach guarantees better performance or compatibility, since those depend on the implementation and the sites involved. 2. Features It helps to separate what the application provides from what its engine provides. Holy Unblocker lineage has included, depending on release: a browser interface with an address or search input, access to different engines, settings for choosing between them, supporting transports, server-side configuration, and extra browsing or privacy options in some versions. Not every feature exists in every release (see Holy Unblocker features). Ultraviolet focuses on request interception, URL rewriting and encoding, configurable behavior and integration with compatible components. As a complete application, Holy Unblocker may offer more user-facing functionality, while Ultraviolet is narrower by design. Counting features without considering their roles would be misleading. 3. Performance There is no universal answer. Performance depends on the engine, server, network, browser and destination site, and an app built on Ultraviolet may perform differently from one using Scramjet. Key factors: Server resources: CPU, memory and throughput (see server requirements). Network latency: distance between user, proxy and destination. Website complexity: many scripts, images and API calls take longer to process. Transport configuration: it affects both compatibility and speed. Browser support: service workers
Holy Unblocker Server Requirements: RAM, CPU, and Hosting Guide
HUHoly Unblocker What It IsHow It WorksFeaturesSupported SitesDownloadGuideFAQ Get it on GitHub Home / Guide / Server Requirements GUIDE · HOSTING Holy Unblocker Server Requirements: RAM, CPU & Hosting Guide Practical starting specs for RAM, CPU, storage, bandwidth and hosting, so you buy what you need and measure the rest. Updated 202611 min readHosting Server resources for Holy Unblocker Four resource gauges for CPU, RAM, storage and bandwidth sit inside a VPS box, showing planning starting points for a small public deployment of 2 vCPUs, 4 GB RAM, 25 to 40 GB SSD and a sufficient transfer allowance VPS · small public deployment (planning estimate) 2 vCPUCPUwatch with top 4 GBRAMwatch with free -h 25–40 GBSSD storagewatch with df -h Transferbandwidth allowanceoften the hidden limit Start modest, measure real usage, then scale. These are planning estimates, not official minimums. Four resources decide how well a server copes. Measure them before you upgrade. Choosing the right server is an important step when hosting Holy Unblocker. A server that is too limited may struggle with multiple users or heavy sites, while buying an expensive one before you need it wastes budget. The project’s long-term development continued as InvisiProxy LTS (see Holy Unblocker vs InvisiProxy), and because it uses several components, requirements vary with the version, configuration and number of visitors. This guide covers realistic starting specs, software dependencies, bandwidth and how to pick a hosting plan. Estimates, not guarantees. The project documentation explains how to prepare a server but sets no universal CPU or RAM minimum. Every figure below is a practical planning estimate. Measure actual usage after installation. 1. What Are the Server Requirements? Server requirements are the hardware and software needed to run an application reliably: processor, memory, storage, network capacity, an operating system and the right software environment. Here are practical starting points: Resource Small test server Initial public deployment CPU 1 vCPU 2 vCPUs RAM 1–2 GB 4 GB Storage 10–20 GB SSD 25–40 GB SSD Network Basic connectivity Reliable connection, sufficient transfer allowance Operating system Supported Linux distribution Ubuntu LTS or another compatible Linux HTTPS Optional for local testing Strongly recommended A small test server may be enough to explore the project or serve very few users. A public instance generally benefits from more memory, CPU and bandwidth, and busy instances may need more still. 2. How Much RAM Does It Need? Holy Unblocker uses a Node.js-based environment and may run several proxy-related components. Memory use depends on the version, enabled features, active sessions, caching and traffic. 1 GB: may suit limited experiments if your version fits. The OS, package installs and background services also use memory. There is little room to grow, so it isn’t dependable for a busy public proxy. 2 GB: a reasonable start for testing or a small deployment. Watch memory under simultaneous sessions, and upgrade if the server leans on swap or kills processes. 4 GB: more room for the app, supporting services and moderate growth. A sensible first target for a small public instance, though not a guarantee for any visitor count. 8 GB or more: extra headroom for larger workloads, but RAM alone won’t fix CPU limits, network throughput, upstream site restrictions or configuration problems. Tip: check real memory usage before upgrading. Monitoring a real workload beats guessing from visitor counts. 3. What CPU Does It Need? The CPU runs the JavaScript-based services and manages concurrent connections. One vCPU is fine for basic testing, two give a small public deployment more capacity, and busier instances may want four or more. The right amount depends on: Concurrent users: more simultaneous activity raises demand. Proxy engines and transports: they can differ in CPU cost (see how Holy Unblocker works). Caching and background tasks: extra services compete for processor time. Heavy websites: complex pages with many requests add load. Configuration: poorly configured services can waste CPU (see how to configure Holy Unblocker). If CPU stays high during normal use, find the cause before buying a bigger plan. Excessive requests, inefficient configuration and heavy sessions can all contribute. 4. How Much Storage Is Required? Storage holds the application files, dependencies, configuration, logs and caches. An SSD gives responsive access to files and packages. For planning, 10–20 GB may do for a basic test environment and 25–40 GB gives a small public deployment more room. These are suggested allocations, not official minimums, and the real amount depends on the release, dependencies, logs and extra software. Check whether your provider lets you expand storage later, and set a retention policy for logs. Don’t delete application files or caches blindly, as some components depend on them. 5. Which Operating System Is Best? A Linux server is a practical choice because it supports the tools web apps commonly use. Ubuntu LTS is beginner-friendly with extensive documentation, and other distributions may work if they support the required runtime. When choosing, consider: Availability of the required Node.js version Compatibility with your selected release Access to Git and the right package manager Support for a reverse proxy such as Nginx Security updates and long-term maintenance Your comfort with the command line Compatibility with the exact version you deploy matters most. Check the official repository instructions rather than assuming every release uses the same runtime or commands. 6. Required Software and Dependencies Hardware alone isn’t enough. The current InvisiProxy repository documents several important dependencies: Node.js: the JavaScript runtime. The required version can differ between revisions, so follow the instructions for your branch. Git: to fetch the source and manage updates or branch switches. Package manager: recent documentation uses pnpm, while older versions may use npm. Use the one and the lockfile that match your release, and don’t mix commands from unrelated versions. Nginx: can act as a reverse proxy for production. The repository warns that some configurations cause problems with WebSocket-like communication or loopback connections, so follow its current deployment guidance. HTTPS and a domain: a public deployment should normally have both, plus DNS records and firewall rules for the services
How to Configure Holy Unblocker: Complete Beginner’s Guide
HUHoly Unblocker What It IsHow It WorksFeaturesSupported SitesDownloadGuideFAQ Get it on GitHub Home / Guide / Configure Holy Unblocker GUIDE · CONFIGURATION How to Configure Holy Unblocker: Complete Beginner’s Guide Find the right files, change settings safely, and fix the problems that bad configuration causes. Updated 202611 min readConfiguration Where Holy Unblocker settings live Three configuration areas: config.json for application options, ecosystem.config.js for port and process settings, and register-sw.js for browser-side service worker and transport settings, all feeding a running instance behind Nginx config.jsonproduction · minifyScriptsverbose · other app options ecosystem.config.jsapplication portprocess manager settings register-sw.jsservice worker · transportsWisp endpoints (browser side) Running instancebehind Nginx and HTTPS Back up, change one thing at a time, restart, test. Settings live in different places. Know which file controls what before you edit. Holy Unblocker is an open-source, browser-based web proxy. Its configuration decides how the app runs, which supporting technologies it uses and how it handles browsing. If you run your own instance, understanding these settings helps you diagnose errors, manage server resources and keep a deployment reliable. Check your version first. Holy Unblocker LTS evolved into InvisiProxy LTS (see Holy Unblocker vs InvisiProxy), so older guides may mention settings or files that have changed. The current repository’s documentation should take priority over outdated instructions. What Configuration Covers It may involve startup, production settings, proxy engines, transports, web server settings and optional routing. For example, you might configure: The port the app uses and whether it runs in production mode How static assets are processed Which transports are available and how Wisp connections are handled How the app is exposed through a domain, and whether optional routing is on Not every setting lives in one file. Some are application config, some are browser-side JavaScript and some belong to the hosting environment. The right configuration depends on the exact version and branch you installed. Before You Start A working installation, and access to the project directory A basic understanding of JSON and JavaScript config files The Node.js version and package manager your release requires A backup of every file you plan to change If you haven’t installed it yet, read How to Self-Host Holy Unblocker first, and confirm instructions against the current InvisiProxy repository. Step 1: Locate the Configuration Files A typical InvisiProxy checkout contains config.json, ecosystem.config.js, package.json and backend.js, plus browser-side files under views. config.json: application-level options. Depending on the release, these include production behavior, script minification, identifier randomization, DOM processing and diagnostic output. Not every option exists in every historical version. ecosystem.config.js: server and process configuration, including the application port and production process settings. Read the comments and current docs before editing. package.json: the scripts and dependencies, which shows the supported commands. Don’t hand-edit dependency versions unless you’re following the project’s development instructions. Browser-side config: the docs identify views/assets/js/register-sw.js for some service-worker and transport settings. It isn’t the server’s main config, and edits affect every visitor to your deployment. Step 2: Back Up Your Configuration cp config.json config.json.backup cp ecosystem.config.js ecosystem.config.js.backup If a file doesn’t exist in your version, don’t create it because a guide lists it. Check your repository’s real structure first. Keep production backups somewhere not publicly reachable from the website. Step 3: Production Mode Production mode is for running the app as a deployed service rather than a development environment. The docs describe a production option tied to process management and other deployment behavior. Verify which file controls it in your release. It can affect how the app starts, whether a process manager is used, how assets are prepared, caching and request handling. Don’t enable it blindly: confirm dependencies are installed and your reverse proxy is configured first. Use development instructions locally and the stable release’s instructions for public deployments. Step 4: The Application Port The documented default address is localhost:8080. A port is the network endpoint where an app accepts connections, so localhost:8080 means port 8080 on the same machine. Other versions may differ. If you change it, find the setting for your release, because the app and any reverse proxy in front of it must agree. If the app listens on 8080 but Nginx forwards to 3000, expect a 502 error. Save the file and check the syntax is valid. Restart using the documented process. Update the reverse-proxy config if needed. Test locally before testing the public domain. Don’t expose internal ports directly to the internet unless you’ve deliberately secured that access. Step 5: The Main config.json Options The repository documents several options. Always verify behavior against your installed release. Option What it relates to Caution minifyScripts Shrinks supported JavaScript assets Doesn’t always make things faster. If builds break, restore the old value. randomizeIdentifiers Experimental identifier randomization for Ultraviolet May change between releases and cause compatibility problems. Read the docs first. production Production-oriented behavior Not a guarantee of security. HTTPS, updates, access control and monitoring still matter. disguiseFiles DOM processing and request presentation Effects vary by release. Test carefully, and don’t expect it to fix compatibility. usingSEO Source randomization involving project data Not a search-engine optimization switch, and it won’t help your website’s rankings. verbose Extra build and diagnostic output Useful for install problems, but detailed logs may record things you don’t want kept in production. Step 6: Proxy Engines and Transports The documentation names Scramjet, Ultraviolet, Wisp, Bare-Mux, EpoxyTransport and LibcurlTransport. They serve different purposes (see how Holy Unblocker works). Scramjet: interception-based engine. Follow the docs for the version bundled with your install. Ultraviolet: service-worker-based engine. Sites can behave differently between it and Scramjet (see Holy Unblocker vs Scramjet). Wisp: communication infrastructure. Its configuration must agree with the rest of your deployment. Bare-Mux: helps manage transport choices. It doesn’t replace correct server, network and dependency setup. EpoxyTransport and LibcurlTransport: transport implementations. Availability depends on release and configuration, and not every one suits every hosting environment. If your Settings menu lets users choose a transport, make sure the selected one is supported and configured before investigating anything else. Step 7: register-sw.js and Service Workers The docs
How to Self-Host Holy Unblocker: Complete Beginner’s Guide
HUHoly Unblocker What It IsHow It WorksFeaturesSupported SitesDownloadGuideFAQ Get it on GitHub Home / Guide / Self-Hosting GUIDE · SELF-HOSTING How to Self-Host Holy Unblocker: Complete Beginner’s Guide Set up your own instance with a VPS, Node.js, Nginx, a custom domain and HTTPS, and keep it running safely. Updated 202612 min readSetup Self-hosting architecture A visitor connects over HTTPS to a domain, which points via DNS to a VPS running Nginx as a reverse proxy in front of the Node.js application on port 8080 Your VPS (Linux) VisitorBrowser DomainDNS A record NginxHTTPS · reverse proxy Node.js applocalhost:8080 · pnpm Keep the app port private. Only Nginx faces the internet. Visitor → HTTPS → Nginx → local application, all on a server you control. Holy Unblocker is an open-source, browser-based web proxy project. Some people prefer running their own instance to relying on a public one, and that is what self-hosting means: installing and running the software on a server you control. It involves getting a server, installing the required software, configuring the project, connecting a domain and maintaining the install. Important update: Holy Unblocker LTS evolved into InvisiProxy LTS, the current continuation of the project (see Holy Unblocker vs InvisiProxy). Check the latest repository documentation before installing an older release. What Self-Hosting Involves VPS: a virtual private server that runs the application. Linux: the operating system you manage it with. Node.js and a package manager: the runtime and dependency installer. Nginx: a web server and reverse proxy in front of the app. Domain and HTTPS: the address visitors use, and encryption for their connections. For example, you buy a VPS, point proxy.example.com at it, run the app locally and let Nginx handle incoming requests. Exact steps depend on the project version and its deployment instructions. For how the pieces work together at runtime, see how Holy Unblocker works. Why Self-Host? Control over configuration: updates, resources, domain settings, and direct access to logs when something breaks. Control over hosting: you choose the provider and who has admin access. That isn’t complete privacy, since the provider can still see infrastructure-level information and the app may log. A custom domain: such as proxy.example.com, but you must own or control the domain. Learning: Linux, DNS, reverse proxies, HTTPS and deployment skills that carry over to other projects. Requirements VPS and operating system A VPS gives you control of the OS and the app process. Check the provider’s acceptable-use policy first, because some restrict public web proxies. A small test deployment may need modest resources, but needs grow with visitors, traffic and version, so watch CPU, RAM, bandwidth, storage and connection limits. A current Ubuntu LTS or another Linux distribution supported by the docs is a good start. The commands below use Ubuntu/Debian package management. Node.js and package manager The runtime must match your chosen version. Older Holy Unblocker and newer InvisiProxy instructions may differ, and the InvisiProxy README has listed Node.js 20.x in one place while showing newer setup elsewhere. Follow the exact runtime requirement for your selected branch and commit. The project currently documents pnpm. Git, Nginx, a domain and basic skills Git downloads the source. Nginx receives public traffic and forwards it to the app, and the README warns about reverse-proxy configuration involving Wisp-related loopback behavior, so read its Nginx instructions before exposing anything. A domain is optional for local tests but useful publicly. You should be comfortable with SSH, running commands, editing config files and reading errors. If you are new to Linux, practice on a test server first. Step 1: Prepare Your VPS Get the server’s public IP and SSH credentials from your host, then connect: ssh your_username@YOUR_SERVER_IP Update the system and install Git, curl and Nginx: sudo apt update sudo apt upgrade sudo apt install git curl nginx sudo systemctl status nginx sudo systemctl enable –now nginx # only if it isn’t running Don’t expose an unfinished app to the public internet before reviewing its configuration and security. Step 2: Install Node.js and pnpm The docs describe Node Version Manager (NVM) as one way to manage versions. Install it from github.com/nvm-sh/nvm, open a new session, then install the version your branch requires (Node 20 shown as an example): nvm install 20 nvm use 20 node -v npm -v Don’t pick a runtime just because it is newer, since dependencies can behave differently across major releases. For pnpm, check whether Corepack is included and follow the project’s documented setup: corepack –version pnpm –version If pnpm isn’t recognized, fix that before continuing, and keep the project’s lockfile intact for reproducible installs. Step 3: Download the Project Decide whether you need historical Holy Unblocker code or the current continuation. For a new deployment, use the official InvisiProxy repository: git clone https://github.com/QuiteAFancyEmerald/InvisiProxy.git cd InvisiProxy Read the README and branch information first. The repository separates development code from deployment-oriented branches and warns that the main development branch can contain work-in-progress changes, so pick an appropriate production branch for self-hosting rather than assuming the newest is the most stable. Step 4: Install Dependencies and Start The repository currently documents this general sequence, but follow your branch’s README if it differs: pnpm run fresh-install pnpm run fetch-adblock pnpm start The first prepares the project and dependencies, the second fetches ad-blocking resources, and pnpm start launches the app. Review scripts before running them, since they execute code on your server. Port 8080 is documented as the default, though it can vary by configuration and branch. For first tests, reach it from the server itself or via an SSH tunnel, and don’t expose the app port publicly unless you’ve deliberately secured it. A test command, pnpm run test, is also documented. If installation fails, common causes are an unsupported Node.js version, missing system dependencies, insufficient memory, network problems or a package-manager mismatch. Read the terminal output before trying random commands. Step 5: Configure the Application The documentation identifies config.json and ecosystem.config.js as relevant configuration files, though options change between releases, so check the current README. Settings can
Holy Unblocker vs VPN: What’s the Difference?
HUHoly Unblocker What It IsHow It WorksFeaturesSupported SitesDownloadGuideFAQ Get it on GitHub Home / Guide / Holy Unblocker vs VPN GUIDE · COMPARISON Holy Unblocker vs VPN: What’s the Difference? Both route traffic through an intermediary, but they work at different layers and offer very different coverage, privacy and security. Updated 20269 min readComparison Holy Unblocker covers the browser, a VPN covers the device Two panels: with Holy Unblocker only the browser session goes through the proxy while other apps use the normal network; with a VPN the browser, apps and games all go through an encrypted tunnel to a VPN server Holy UnblockerBrowser-based web proxy VPNDevice / network level tunnel Browser Other apps Games Browser Other apps Games Proxy EncryptedVPN tunnel Only the proxied web session All traffic routed through the VPN Holy Unblocker focuses on the web browser. A VPN focuses on the network connection. Holy Unblocker and VPNs can both send traffic through an intermediary server, but they are built for different purposes. A VPN (Virtual Private Network) normally works at the device or network level, creating an encrypted connection between your device and a VPN server. Holy Unblocker is browser-based web proxy technology that processes websites inside the browser through proxy engines. Is Holy Unblocker a VPN? No. It is a browser-based web proxy platform that uses proxy engines and transport systems to retrieve and process web content. It doesn’t offer the same functionality, privacy model, encryption or coverage as a VPN. What Is Holy Unblocker? An open-source web proxy project that lets you reach websites through a browser-based proxy environment, with no VPN application to install. It can use engines such as Scramjet and Ultraviolet along with Wisp and transport systems (see how it works). Your browser -> Holy Unblocker -> Proxy system -> Website That suits reaching web content without a separate networking app, but it shouldn’t be confused with a full-device VPN. What Is a VPN? A VPN connects your device to a VPN server and routes supported traffic through that connection. Your device -> Encrypted VPN tunnel -> VPN server -> Internet Depending on the implementation and operating system, it can cover several applications rather than one browser tab: Web browsers and desktop applications Mobile apps and game clients Messaging apps and other network software Quick Comparison Feature Holy Unblocker VPN Type Browser-based web proxy Virtual Private Network Installation Usually browser/web based Usually an app or configuration Coverage Primarily browser/web traffic Can cover device or network traffic Encryption Depends on connection and deployment Tunnel encrypts traffic to the VPN server Changes public IP Can, depending on setup Generally yes Protects all device traffic No Usually, if set up as full-device VPN Desktop apps Generally no Yes, depending on setup Website proxying Core purpose Not its primary purpose Open source Yes Depends on provider Website compatibility Depends heavily on proxy engine Depends on site, VPN IP and network Privacy Depends on deployment and operator Depends on provider and configuration The key point is that they operate at different layers. Is Holy Unblocker a VPN? No. A VPN creates a network-level connection between your device and a server, while Holy Unblocker provides a browser-based environment for accessing sites through proxy technology. Opening a site through it doesn’t automatically give the protection of connecting your whole device to a VPN. With a VPN, other applications can also use the connection. With a browser proxy, the proxy generally applies to the web session it handles, which matters for privacy, applications, games and downloads. How Each One Works Holy Unblocker retrieves a site and processes its content before showing it to you, intercepting and rewriting requests and handling browser resources so the site works through the proxy. Scramjet is designed for exactly this (see Holy Unblocker vs Scramjet). Browser -> Holy Unblocker -> Proxy engine -> Website -> Proxy engine -> Browser A VPN routes supported traffic through a tunnel to its server, and the site generally sees the VPN server’s address instead of yours. Application -> Device VPN -> Encrypted tunnel -> VPN server -> Internet A VPN is concerned with network traffic. Holy Unblocker is concerned with web content and browser-based proxying. Privacy and Hiding Your IP Neither a web proxy nor a VPN makes you completely anonymous. A VPN can hide your public IP from sites, but the provider may be able to observe or handle network information depending on its architecture, policies and logging. With Holy Unblocker, the deployment matters: on someone else’s instance you are trusting that operator and its infrastructure. Don’t assume “nobody can see my activity.” A proxy can stop the destination from seeing your original IP the way it would on a direct connection, because an intermediary handles the request. But your connection to the proxy server still exists, and its operator may see information tied to it. Think of Holy Unblocker as routing web requests through a proxy, not as a complete anonymity system. With a VPN, sites normally see the VPN server’s IP instead of your connection’s. Yet changing your visible IP isn’t anonymity: sites can still identify users through accounts, cookies, browser characteristics, device information and tracking. IP masking ≠ complete anonymity. See our disclaimer. Security A VPN can encrypt traffic between your device and the VPN server, depending on protocol and configuration, which helps on networks you don’t fully trust. Holy Unblocker provides no universal encrypted tunnel for your device. Its security depends on the site’s connection, the deployment and the technologies in use. If the Holy Unblocker site is reached over HTTPS, the connection between your browser and it is protected, but that isn’t equivalent to a VPN protecting all device traffic. Website Access A VPN changes the network path your device uses. A browser proxy retrieves and processes web content, which can help with sites that behave differently depending on how requests are made: rewriting URLs, intercepting requests, processing page resources and handling browser-side scripts. Modern sites can still break through a
Why Websites Don’t Work on Holy Unblocker: Common Causes and Fixes
HUHoly Unblocker What It IsHow It WorksFeaturesSupported SitesDownloadGuideFAQ Get it on GitHub Home / Guide / Why Websites Don’t Work GUIDE · TROUBLESHOOTING Why Websites Don’t Work on Holy Unblocker: Common Causes and Fixes A site that fails inside the proxy isn’t proof the proxy is down. Learn how to tell the difference and what to try. Updated 202610 min readTroubleshooting Direct connection works but the proxied site fails A site that loads directly but fails through Holy Unblocker, with likely causes: JavaScript, CAPTCHA, WebSockets, authentication and site restrictions Direct connection Browser → Website Through Holy Unblocker Browser → Proxy → Website JavaScript CAPTCHA WebSockets Login / cookies Site blocks Most likely causes when only one site fails If other sites work through the proxy, the problem is usually that one site’s compatibility. Holy Unblocker works with many websites, but it is normal for some sites or individual features to fail in a browser proxy. A site may load partly, show a blank screen, hang, show a CAPTCHA, return a 502 error, or work fine outside Holy Unblocker and fail inside it. That doesn’t mean the proxy is completely down. Modern sites combine JavaScript, APIs, cookies, WebSockets, authentication and security policies, and a browser proxy has to process all of it. The project lineage continues as InvisiProxy LTS (see Holy Unblocker vs InvisiProxy), and its documentation acknowledges that CAPTCHA support is inconsistent and some sites may not work through the available engines. Start here: if every site fails, suspect the proxy or your browser. If only one site fails, suspect that site’s compatibility. For a broader checklist, see 10 common problems and fixes. Why Don’t Websites Work on Holy Unblocker? There isn’t one reason. A site can fail because of proxy compatibility, JavaScript, CAPTCHA, WebSockets, authentication, browser compatibility, cached data, proxy-server errors, site-side restrictions or heavy architecture. What matters is finding where the problem occurs. 1. The Site Isn’t Fully Compatible With the Proxy The most common cause. Scramjet’s approach combines interception, rewriting and sandboxing (see how Holy Unblocker works), which suits many sites, but a site can depend on unusual technologies: Complex JavaScript and dynamic API requests WebSockets and browser storage Strict security policies and authentication systems Embedded third-party services If one important part can’t be processed, the page may only partly work. Try another site first. If others work normally, the cause is that specific site. 2. JavaScript Problems A modern web app uses JavaScript for navigation, login, search, API calls, interfaces, video players and real-time updates. If the proxy can’t handle how a site uses it, you may see blank pages, buttons that do nothing, missing content, endless loading, broken menus or failed logins. Refresh, then try another browser, clear site data, try another engine and test a different site. 3. CAPTCHA May Not Work CAPTCHAs check whether a visitor is a real user, and a proxy can trigger them because the site sees an unfamiliar network environment. The documentation notes CAPTCHA support is inconsistent across proxy implementations, with Scramjet offering the strongest support. You may see loops, CAPTCHAs that never load, “verify you are human” prompts or pages that never progress. Reload, or try another available engine or browser. Wait and try later. Don’t keep refreshing the verification page, which can make it worse. If the CAPTCHA itself is incompatible, there may be no reliable client-side fix. 4. The Site Uses WebSockets WebSockets keep a persistent two-way connection, and chat apps, multiplayer games, dashboards, collaboration tools and notifications use them. A site can load and log you in while its real-time features fail (chat doesn’t update, a multiplayer connection drops). The first HTTP requests may work while the persistent connection doesn’t. Try a simpler mode of the site, or another engine or transport if offered. 5. The Site Blocks or Restricts Proxy Traffic Some sites restrict proxy traffic for reasons such as abuse prevention, bot protection, rate limiting, fraud prevention, geographic rules or network reputation. If it works directly but fails through Holy Unblocker while other sites work through it, the problem is specific to that destination’s handling of the proxy, not necessarily a Holy Unblocker fault. 6. Strict Security Policies Browsers and sites enforce policies affecting cross-origin requests, cookies, scripts, embedded content, frames, API requests and resource loading. A proxy changes the environment those resources are requested in, so a site may load its HTML but fail to load an API or script it needs. 7. Login and Authentication Break Login systems are sensitive to proxy environments. Secure cookies, tokens, OAuth, third-party identity providers, device checks and security challenges can all fail, producing login loops, “session expired” messages, blank login pages or sudden logouts. First check that the site works without the proxy. If direct access works but authentication always fails through the proxy, the login system likely isn’t compatible. For important accounts, avoid entering sensitive credentials on an untrusted public proxy (see our disclaimer). 8. Your Browser or Cached Data Sometimes the site isn’t the problem. Outdated cache, corrupted site data, conflicting extensions, disabled JavaScript, service-worker issues or old browser components can all break things. Proxy apps use service workers and client-side resources, and old cached ones can conflict with a newer deployment, which is a common reason something that worked yesterday fails today. Open Holy Unblocker in a private window. If the site works, an extension or stored data was the cause. Try another browser, such as Firefox or Edge if you use Chrome. Close the tab, clear site data for the deployment, reopen the browser and reload. You don’t need to delete your whole history. 9. A 502 Error A 502 Bad Gateway generally means a problem between the client and the upstream server. The documentation recommends trying another site or waiting, and says clearing the cache can sometimes help. Refresh, try another site, clear the relevant cached data, then wait. If many sites return 502 at once, the deployment is more likely at fault than the destination. 10. The Server
How Does Holy Unblocker Work? A Complete Technical Guide
HUHoly Unblocker What It IsHow It WorksFeaturesSupported SitesDownloadGuideFAQ Get it on GitHub Home / Guide / How Holy Unblocker Works GUIDE · TECHNICAL How Does Holy Unblocker Work? A Complete Technical Guide Follow a request from your browser through the proxy engine, Wisp and the transport layer to the destination, and back. Updated 202612 min readArchitecture Holy Unblocker layered architecture A vertical stack from the browser through the Holy Unblocker interface, the proxy engine (Scramjet or Ultraviolet), Wisp, Bare-Mux, the Epoxy and Libcurl transports and the proxy server to the destination website Your browser Holy Unblocker interface Proxy engine: Scramjet / Ultraviolet Wisp Bare-Mux Epoxy Libcurl Proxy server → destination site Intercepts, rewrites,sandboxes contentProtocol layerSwitches transports Each layer solves one part of the problem, and the response returns through the same layers. If you’ve wondered how Holy Unblocker works behind the scenes, the answer is more involved than sending an address through a proxy. It is a browser-based web proxy built from several cooperating technologies: Scramjet, Ultraviolet, Wisp, Bare-Mux, EpoxyTransport and LibcurlTransport. The LTS project also continues as InvisiProxy LTS (see Holy Unblocker vs InvisiProxy), so modern explanations need to account for that lineage. At a high level: your browser → Holy Unblocker interface → proxy engine → transport layer → proxy server → destination website, with the response returning along the same path. The Basic Idea A normal request goes straight from the browser to the website. A browser proxy adds layers, and it can’t hand you the original site untouched: it must process links, scripts and requests so they keep working inside the proxied environment. Normal: Browser -> example.com Proxied: Browser -> Holy Unblocker -> Proxy infrastructure -> example.com Unlike a VPN, which generally works at the network level, Holy Unblocker is built around browser web technologies. It is not a simple redirect either. A redirect just sends you elsewhere, while a proxy has to process requests, resources and browser behavior so the destination operates through it. What Happens When You Enter a URL Take https://example.com. A simplified flow looks like this (real implementations are more complex): 1Holy Unblocker routes the URL to the proxy environment2A proxied browsing context is created3The engine intercepts requests the page makes4URLs and resources are rewritten5The transport carries the request6The proxy server contacts the site7The response returns and the browser renders it The homepage overview shows the same flow in four short steps. The Interface and the Browser It starts with the browser interface, but the browser isn’t just displaying Holy Unblocker. It is part of the proxy environment. The app has to maintain its own browser-side environment while handling requests made by the destination, which is why JavaScript, service workers, workers and iframes matter. Modern browser APIs provide: Request interception and service workers JavaScript execution and storage WebSockets and WebAssembly Sandboxing That is why browser compatibility matters so much, and why a browser update can change behavior a proxy depends on. It is also how Holy Unblocker works without a traditional desktop app. The Proxy Engine The engine makes the web app operate through the proxy. Implementations can use Scramjet, Ultraviolet and, in some deployments, Rammerhead. InvisiProxy’s documentation names Scramjet and Ultraviolet as its web proxies, with Wisp in their communication architecture. Scramjet: interception, rewriting, sandboxing Scramjet describes itself as an experimental interception-based web proxy. See Holy Unblocker vs Scramjet for how it relates to the platform. Interception: a page requests /style.css, /app.js and an API endpoint. Instead of going straight out, those requests are intercepted and routed through the proxy. Rewriting: references like <script src=”/app.js”>, <img src=”/image.png”> and <a href=”/account”> must be processed, or the browser would request them directly from the original site. Sandboxing: the site’s JavaScript was written to run on its own domain. A sandbox gives it a controlled environment so it can run without taking over the surrounding app. Service workers and Ultraviolet A service worker sits between a page and its network requests, giving a browser proxy the chance to process requests before they are handled normally. That suits modern sites, which generate many requests dynamically. Ultraviolet uses service-worker techniques too and remains available beside Scramjet. Different sites behave differently through different engines, so having both helps. Wisp, Bare-Mux and Transports Wisp is the protocol and server-side communication layer used by Scramjet and Ultraviolet, bridging the browser-side engine and the transport. Bare-Mux manages transports: picture several roads for the traffic, with Bare-Mux choosing and switching between them. Two transports are available: EpoxyTransport: optimized for Chromium and Apple environments in the current interface. LibcurlTransport: a cross-browser option, using a WebAssembly-based networking library inside the browser. Engine -> Wisp -> Bare-Mux -> EpoxyTransport -> Proxy server -> LibcurlTransport -> Proxy server Different environments have different compatibility needs, so switching a transport can sometimes fix a problem. See troubleshooting for when to try that. The Proxy Server and the Response Browser-side components can’t reach the internet on their own, so server-side infrastructure connects the request to the destination. When the site responds with HTML, CSS, JavaScript, images and API data, the proxy hands them to the browser through the proxied environment, which renders the result. For a simple page that is straightforward. A modern app can generate hundreds or thousands of requests, including scripts, fonts, analytics, WebSockets and media. Why Modern Websites Are Hard to Proxy Older sites were simple: HTML with CSS, images and some JavaScript. Modern ones add JavaScript bundles, APIs, WebSockets, authentication, cookies, service workers, dynamic imports, media, browser storage and third-party services. If one important piece isn’t compatible, a site may partly work or fail entirely, which is why one site runs fine while another shows a blank screen. JavaScript, cookies and WebSockets JavaScript: it contains absolute and relative URLs, API endpoints, dynamic imports, WebSocket connections, browser API calls and security checks that must all be processed correctly. Scramjet uses interception, rewriting and sandboxing for this. Cookies: sites expect them to belong to their own context. Poor handling causes repeated login prompts, broken sessions
Holy Unblocker Not Working? 10 Common Problems and Fixes
HUHoly Unblocker What It IsHow It WorksFeaturesSupported SitesDownloadGuideFAQ Get it on GitHub Home / Guide / Holy Unblocker Not Working GUIDE · TROUBLESHOOTING Holy Unblocker Not Working? 10 Common Problems and Fixes Blank screens, slow pages, connection errors and broken features. Find where the problem is first, then fix it. Updated 20269 min readTroubleshooting Troubleshooting flow for Holy Unblocker problems A decision flow: if the proxy page does not load, check browser, network and server; if it loads but one site fails, check site compatibility; if everything is slow, check region and transport; if features break, try another engine Something is not workingIsolate the problem first Proxy page won’t loadBrowser · network · server One site failsSite compatibility · engine Everything is slowRegion · transport · load Features brokenJavaScript · APIs · cookies Try another browser,clear site dataTry another engine,test another siteCloser region,another transportReload, clear data,switch engine Work out which of the four situations you are in before changing any settings. Holy Unblocker provides browser-based proxy access to websites, but like any web proxy it can stop working as expected. You might see a blank screen, a site that won’t load, a connection error, slow performance, broken images or missing buttons. These problems don’t always mean Holy Unblocker is down. The cause can be your browser, the destination website, the proxy engine, transport configuration, server load, your network or a compatibility issue. This guide covers 10 common problems in 2026 with practical fixes. Note: Holy Unblocker LTS continued as InvisiProxy LTS, so some troubleshooting applies to the newer implementation and its components, including Scramjet, Ultraviolet and different transports. See Holy Unblocker vs InvisiProxy. 1. Holy Unblocker Is Not Loading at All You may see a blank page, a browser timeout, “This site can’t be reached”, connection refused, DNS errors or a loading screen that never finishes. Why it happens The public instance may be unavailable or overloaded, the domain may have changed, or there may be a network or DNS problem. Corrupted cache or service-worker data in your browser can also cause it. How to fix it Refresh, then hard refresh (Ctrl + F5 on Windows). Try another browser. If it works there, the cause is your original browser’s cache, extensions or stored site data. Check your connection by opening several normal websites. If they fail too, Holy Unblocker isn’t the problem. Try again later. If only this deployment is unavailable, it may be down for an outage or maintenance. 2. Holy Unblocker Shows a Blank Screen The main interface loads, but the site you requested stays white. Possible causes include JavaScript compatibility problems, proxy rewriting issues, service-worker problems, browser restrictions, website-specific incompatibility, cached proxy data or the selected proxy engine. Modern sites are applications built on JavaScript, APIs, cookies and WebSockets, not simple HTML pages. Reload, then exit and enter the destination again. Clear site data for the Holy Unblocker deployment. Try another browser to see if it is browser-specific. Try another proxy engine if available. InvisiProxy includes Scramjet and Ultraviolet, and compatibility can differ between them. If one fails and another works, the issue is that site’s compatibility with the engine. See Holy Unblocker vs Scramjet. 3. Holy Unblocker Is Extremely Slow Symptoms include slow loading, delayed images, video buffering, slow JavaScript and high latency. Proxying adds a layer: instead of your browser → website, the path is your browser → proxy → website. A server far from you adds more latency. Choose a closer region if the deployment offers region selection. Close unnecessary tabs. JavaScript-heavy proxied sites use a lot of CPU and memory. Test a simple website. If simple sites are fast and complex apps are slow, it’s site-specific. Try another transport (Epoxy or Libcurl) if offered, which may improve compatibility or speed. 4. A Website Opens but Some Features Don’t Work Login fails, images are missing, buttons don’t respond, search breaks, videos won’t play, menus won’t open, downloads fail or some pages stay blank. Sites depend on JavaScript, API requests, cookies, WebSockets, service workers, browser storage, content-security policies and cross-origin requests, and if one piece isn’t compatible with the proxy environment, part of the site breaks. Reload, then reopen the site through the proxy. Try another browser and another available engine. Clear the site’s stored data. Test a different website. If other sites work and only one doesn’t, it is probably site compatibility rather than a full outage. 5. Holy Unblocker Says Connection Failed This appears when the proxy can’t establish or keep communication with the destination. Causes include destination-server restrictions, proxy-server problems, network instability, DNS problems, transport failure, overload or website-side blocking. Check whether the destination works without the proxy. If it is down, Holy Unblocker can’t fix that. Try another website through the proxy. Every site fails: the deployment, browser or network is the likely cause. One site fails: it may be incompatible with the proxy or actively restrict proxy traffic. Changing browser settings won’t fix a site-side restriction. 6. It Works on One Browser but Not Another Holy Unblocker may work in Chrome but fail in Firefox, or behave differently on mobile. Browsers implement web technologies differently, and proxies depend on service workers, JavaScript and storage APIs, WebSockets, fetch requests and security policies. The InvisiProxy roadmap includes Firefox and mobile compatibility work. Update the browser and restart it. Temporarily disable extensions. Clear site data. Test a second browser and compare. If it works elsewhere, you’ve found a browser-specific issue. 7. It Stops Working After a Browser Update Updates can change service workers, storage, cross-origin behavior, JavaScript APIs, network requests and security restrictions, so a previously working proxy can hit new compatibility problems. Fully close and reopen the browser. Clear the site’s cached data and reload. Test another browser, and check whether it happens on multiple devices. If you self-host, check the project’s documentation and updates. Avoid immediately changing advanced browser security settings. Changing controls you don’t understand can create more problems. 8. It Doesn’t Work on Mobile You might see blank
Holy Unblocker Features: Everything You Can Do With It in 2026
HUHoly Unblocker What It IsHow It WorksFeaturesSupported SitesDownloadGuideFAQ Get it on GitHub Home / Guide / Holy Unblocker Features GUIDE · FEATURES Holy Unblocker Features: Everything You Can Do With It in 2026 Proxy engines, transports, privacy options, self-hosting and more. Here is what each feature does and what to expect from it. Updated 20269 min readFeatures Holy Unblocker feature map A central Holy Unblocker and InvisiProxy node connected to feature nodes: proxy engines, transports, privacy, self-hosting, region selection and compatibility HU Holy Unblockernow InvisiProxy LTS Proxy enginesScramjet · Ultraviolet TransportsWisp · Bare-Mux · Epoxy · Libcurl CompatibilityModern sites · mobile · Firefox PrivacyHidden history · Tor routing Region selectionLatency and routing Self-hostingOpen source · configurable The modern Holy Unblocker ecosystem is a set of cooperating features, not a single page. If you’re looking for a browser-based proxy with more functionality than a basic web proxy, Holy Unblocker is worth understanding beyond its name. Its LTS project continued under the InvisiProxy name, and the current project combines several technologies designed for browser-based proxying, website compatibility, transport flexibility, privacy-oriented browsing and self-hosting. Depending on the deployment and version, you can get multiple proxy engines, different transport options, privacy features, self-hosting and compatibility tools. This guide explains the major features and what each one does. What Is Holy Unblocker? Holy Unblocker was an open-source browser-based web proxy project. Unlike a traditional VPN application, a browser proxy works through the browser, rewriting and processing website resources so a remote site can be displayed through the proxy interface. The LTS project now continues as InvisiProxy LTS, which its documentation identifies as formerly Holy Unblocker LTS, listing Scramjet, Ultraviolet, Wisp, Bare-Mux, EpoxyTransport and LibcurlTransport. Some current functionality belongs to this newer generation. See Holy Unblocker vs InvisiProxy for the full story. Features at a Glance Browser-based web proxying and clientless browsing Scramjet and Ultraviolet proxy support Wisp, Bare-Mux, Epoxy and Libcurl transports Hidden history and Tor/Onion routing Region selection in supported deployments Self-hosting and an open-source architecture Browser compatibility work and ongoing updates Not every public deployment exposes every feature. Configuration, version and server setup affect what you can access. 1. Browser-Based Web Proxy The most fundamental feature. Instead of installing a desktop VPN client, you use the proxy through a browser interface, and it processes the requested site through its own infrastructure. It is not a VPN: a VPN generally works at the network level, while a browser proxy focuses on web traffic handled through the proxy environment. 2. Scramjet Support Scramjet is an interception-based web proxy that uses rewriting and sandboxing to process sites inside the browser. InvisiProxy lists it as a web proxy and recent releases keep updating the integration. It matters because modern sites rely on JavaScript, dynamic requests and APIs, so a proxy has to do more than download HTML. Read more in Holy Unblocker vs Scramjet. 3. Ultraviolet Support Ultraviolet is another browser-based proxy that uses service-worker techniques. Having it next to Scramjet is useful because sites behave differently, and if one implementation has problems, another may do better. That is why the project doesn’t rely on a single proxy technology. 4. Multiple Transport Options Transport is the layer that carries proxy requests between the browser and the proxy infrastructure. The project includes EpoxyTransport and LibcurlTransport, which can differ in compatibility and performance. One may suit a particular browser while another offers broader compatibility. 5. Wisp Integration Wisp provides proxy communication infrastructure used by technologies such as Scramjet. The architecture has several layers: Websitethe destinationProxy engineScramjet / UltravioletWispcommunicationTransportEpoxy / LibcurlProxy serverto the web This design lets individual components be updated without replacing the whole application. You can see the basic flow in how Holy Unblocker works. 6. Bare-Mux Support Bare-Mux lets browser applications manage and switch between proxy transports. Rather than hard-coding one connection method, a transport-management layer helps the proxy pick an appropriate one, which gives developers extra flexibility. 7. Clientless Browsing No dedicated VPN client or desktop app is needed. The interface runs inside a modern browser, which makes the concept accessible, but it also makes browser compatibility an important part of the experience. 8. Privacy-Oriented Features The v7 line added features such as hidden history and protections against certain tab leaks, which reduce some kinds of exposure through the browser interface. They don’t make a proxy anonymous. Depending on architecture, destination and configuration, the proxy operator can still see certain traffic. 9. Tor and Onion Routing In supported deployments, Tor/Onion routing sends traffic through multiple relays rather than a single proxy connection, which can add privacy characteristics. It also adds latency, so it suits cases where privacy matters more than speed. Combining technologies still doesn’t guarantee complete anonymity. 10. Region Selection Some deployments let you choose between proxy regions, which can affect latency, speed, website behavior and geographic routing. A closer server can sometimes reduce latency. Available regions depend on the deployment: a self-hosted install may have one location, a larger one several. 11. Self-Hosting A key feature for developers: rather than relying on a public instance, you can deploy the software on your own server, following the project’s documented requirements. See our self-hosting section for the steps. Greater control over the server and configuration Ability to customize the interface A clearer view of where traffic is processed Your own deployment to maintain It also means you are responsible for dependencies, security, updates, networking and server resources. 12. Open-Source Architecture The InvisiProxy repository is public, so developers can inspect the code, study the architecture and contribute. Unlike proprietary proxy services, you can see how it works, and it doubles as a learning resource for browser proxying, transports and web rewriting. 13. Multiple Proxy Engines The architecture doesn’t depend on one engine. Scramjet and Ultraviolet have different implementation details and compatibility characteristics, so there is an alternative when a site misbehaves through one, and developers can experiment without rebuilding the platform. 14. Website Compatibility The design targets modern sites, which commonly use: JavaScript, APIs and dynamic