FRP Domain
The FRP domain is used to access FRP STCP / XTCP visitor resources.
OmniGate's FRP design is split into two layers:
- The domain layer stores frpc client configuration.
- The resource layer stores visitor configuration.
Domain Layer Configuration
| Field | Description |
|---|---|
| Name | Domain display name |
| clientID | frpc client ID, optional |
| user | frpc user, usually needs to match the server configuration |
| serverAddr | frps address |
| serverPort | frps port, default 7000 |
| auth.token | frps token |
| transport.protocol | tcp, kcp, or quic, default tcp |
Resource Layer Visitor Configuration
FRP resources do not require manually entering a local address and port. OmniGate automatically assigns 127.0.0.1:<random port> to avoid port conflicts.
The following fields are required at the resource layer:
| Field | Description |
|---|---|
| Visitor Type | STCP or XTCP |
| serverUser | The peer frpc's user, must match the publishing side |
| serverName | The peer proxies.name, for example ssh or web |
| secretKey | The peer proxies.secretKey |
The second line of the resource list displays serverUser.serverName for easy identification of which FRP service is being connected to.
What Happens When Opening a Resource
- OmniGate logs into frps based on the domain configuration.
- Starts a visitor based on the resource configuration.
- Binds a random available local port.
- The Web, SSH, file, or VNC client accesses that local port.
Common Issues
frps reports client_id already online
The same user + clientID cannot be online simultaneously. Suggestions:
- Do not use the exact same clientID on multiple devices.
- If you repeatedly tap the same resource, OmniGate will try to reuse the existing visitor session, but the server may still experience brief conflicts if old connections are not fully released.
custom listener doesn't exist
This is usually because the serverUser or serverName at the resource layer is incorrect. The serverUser must match the frpc user of the publishing side.
SSH connects via FRP but authentication fails
First, verify that the same SSH resource works under direct connection. FRP only handles TCP forwarding; SSH authentication is still determined by the target sshd. When using private key authentication, make sure the correct key is selected in the SSH resource configuration.