How Does Holy Unblocker Work? A Complete Technical Guide

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.

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):

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 and unexpected logouts.
• WebSockets: persistent two-way connections used by chat, multiplayer games, dashboards and notifications. Without proper support, a site may load while its real-time features fail.

Tor and SOCKS5 Routing

Some deployments support SOCKS5, HTTP/HTTPS proxy routing and Tor/Onion routing. The chain becomes Browser → Holy Unblocker → engine → transport → SOCKS5 or Tor → destination. Extra hops add latency and are not a guarantee of anonymity.

Why It Can Be Slow, and Why Some Sites Fail

Every added stage can add latency. Speed depends on your connection, proxy-server and destination locations, server load, engine, transport, website complexity and browser performance. A light page feels fast and a JavaScript-heavy app feels slower.

No proxy guarantees compatibility with every site. Common reasons for failure:

• Architecture: the site uses technologies not fully compatible with the proxy.
• Security policies: the site may actively restrict proxy traffic.
• Browser APIs: some behave differently in a proxied environment.
• Real-time connections: WebSockets or persistent connections may not work.
• Authentication: some logins are sensitive to domain and browser context.
• Constant updates: a site can change its architecture without warning.

Scramjet itself lists supported sites while calling the proxy experimental, which shows compatibility is an ongoing engineering matter.

A Simple Proxy vs This Architecture

Basic proxy:   Browser -> Proxy -> Website

Holy Unblocker: Browser -> Web interface -> Proxy engine
                -> Interception / rewriting / sandboxing
                -> Wisp -> Bare-Mux -> Transport
                -> Proxy server -> Website

The extra complexity exists because modern sites are far more complicated than documents. The layered design gives you:

• Flexibility: multiple engines and transports.
• Compatibility: different technologies for different site and browser needs.
• Maintainability: components update without redesigning everything.
• Self-hosting and extensibility: open-source parts you can modify.

The tradeoff is more potential points of failure. See Holy Unblocker features for what each part offers.

Self-Hosting

With a self-hosted install you control the server running the proxy infrastructure: your browser → your installation → your server → the destination. The InvisiProxy repository provides deployment instructions and lists Scramjet, Ultraviolet, Wisp, Bare-Mux, EpoxyTransport and LibcurlTransport (see our self-hosting section). You become responsible for server security, updates, dependencies, configuration, performance, connectivity and maintenance.

Does It Hide Your IP? Is It a VPN?

A proxy changes the path a site sees, so the destination may see the proxy's connection instead of your device's, depending on deployment and routing. But privacy involves more than IP addresses: cookies, accounts, browser characteristics and login information can still identify or correlate activity, and the proxy operator may see parts of the traffic. Don't treat it as a universal anonymity tool, and see our disclaimer.

It is also not a VPN. A VPN routes traffic from multiple applications at the network level (Device → VPN → Internet), while Holy Unblocker handles web traffic inside the browser (Browser → Proxy app → Proxy server → Website). They solve different problems.

Common Misunderstandings

• "It's just a URL redirect." No. It processes requests, resources and browser behavior.
• "Every website will work." No. Compatibility is never absolute because sites constantly change.
• "A proxy means complete privacy." No. Accounts, cookies and operator visibility still matter.

Architecture Summary

USER -> Web browser -> Holy Unblocker UI
     -> Proxy engine (Scramjet / Ultraviolet / Rammerhead)
     -> Wisp layer -> Bare-Mux
        -> EpoxyTransport | LibcurlTransport
     -> Proxy server -> Destination website

(The response returns through the same layers.)

• Scramjet / Ultraviolet: handle web proxying.
• Wisp: proxy communication protocol and infrastructure.
• Bare-Mux: manages and switches transports.
• Epoxy / Libcurl: transport implementations.
• Server: connects the system to the destination network.

Frequently Asked Questions

Final Thoughts

Holy Unblocker is far more sophisticated than a page that forwards URLs. A browser interface sits on top of proxy engines, request interception, rewriting, sandboxing, communication protocols and transport systems, with server infrastructure connecting everything to the destination.

Related Guides