Web Browser

Web resources are opened using the OmniGate built-in browser. Resource configuration uses a full URL.

Navigation Bar

The navigation bar on web pages displays the page title and is not editable. When the page title is empty, the resource name is shown.

During the connection process, the navigation bar first displays the two-step connection progress (domain -> resource). Once the page finishes loading, it switches to the page title.

Configuration

Field	Description
Name	Resource display name
URL	Full address, for example http://192.168.1.1/

Access Path

When opening a Web resource:

1. OmniGate activates the domain that the resource belongs to.
2. The browser waits for the domain proxy to become ready.
3. The browser loads the URL.

Different domains use different paths:

• None: Direct access.
• WireGuard: Access through the built-in WireGuard proxy.
• Tailscale: Access through the built-in Tailscale SOCKS5 or session.
• ZeroTier: Access through the built-in ZeroTier local proxy.
• FRP: Starts a visitor first, then accesses the random local port.

Adding the Current Page as a Resource

The web page menu allows you to add the current page as a resource. When saving, the app checks whether a Web resource with the same name or the same URL already exists under the current domain. Duplicates are rejected with a notification.

HTTP and HTTPS

OmniGate supports both http and https. If an HTTP page won't open and you see an App Transport Security error, it usually means the URL did not properly enter the built-in proxy channel, or it was blocked by system security policies.

WebSocket

Some pages use WebSocket, for example:

ws://172.31.1.4:3000/api/live/ws

OmniGate tries to route WebSocket traffic through the current domain, but WebKit, proxy type, HTTP/HTTPS mixed content, and server-side protocols can all affect compatibility.

If the page HTML loads but real-time data, console, or charts don't refresh, first check the browser developer logs for the WebSocket URL and whether the target domain is reachable.

Basic Authentication

Pages requiring Basic authentication should trigger the authentication flow through WebKit or the proxy layer. If the server returns 401 Unauthorized without showing a login dialog, usually you need to check:

• Whether the URL is correct.
• Whether the server only allows access from specific origins.
• Whether the current page is going through a proxy instead of direct connection.
• Whether authentication occurs on a WebSocket, Ajax, or redirected URL.
• Whether the username and password are correct.

Basic authentication credentials can be embedded in the URL to avoid entering them each time, for example: http://user:pass@192.168.1.1/