frp (Fast Reverse Proxy) is a lightweight, high-performance reverse proxy tool that lets you expose local services through a public server. It's widely used in self-hosted setups to make internal services accessible without complex firewall rules or VPN infrastructure — a single frps process on a VPS forwards traffic to frpc clients running behind NAT. But when frps crashes or a client disconnects, proxied services vanish silently. Vigilmon gives you the visibility to catch these failures before your users notice.
What You'll Set Up
- HTTP monitor for the frps dashboard
- Proxied service endpoint health checks
- Admin API monitor for frp server status
- Connection status monitoring via the admin API
- Alert channels for immediate notification
Prerequisites
- frp v0.51+ with
frps(server) running on a public host - Dashboard enabled in
frps.toml(orfrps.inifor older versions) - Admin API enabled on
frpc(client) if monitoring connection status from client side - At least one active proxy forwarding traffic
- A free Vigilmon account
Step 1: Monitor the frps Dashboard
frp's server component ships with a built-in web dashboard that shows proxy statistics, connection counts, and client status. It's also the quickest health signal for the frps process itself.
Enable the dashboard in frps.toml:
[webServer]
addr = "0.0.0.0"
port = 7500
user = "admin"
password = "your-dashboard-password"
Then monitor it with Vigilmon:
- Log in to vigilmon.online and click Add Monitor.
- Set Type to
HTTP / HTTPS. - Enter the URL:
http://<your-frps-host>:7500. - Set Expected HTTP status to
200. - Set Check interval to
2 minutes. - Click Save.
The dashboard returns 200 with HTML when frps is running. A connection refused or 502 indicates the frps process has stopped — the most common failure mode after server reboots or out-of-memory kills.
If you've placed the dashboard behind a reverse proxy with HTTPS, monitor the HTTPS URL instead and add an SSL certificate check (Step 5).
Step 2: Monitor Proxied Service Endpoints
The most business-critical health check is whether your proxied services are actually reachable through frp. Each proxy configured in frp should have its own Vigilmon monitor.
For an HTTP proxy forwarding a web service:
- Add Monitor →
HTTP / HTTPS. - URL:
http://<your-frps-host>:<exposed-port>(the port frps listens on for this proxy, e.g.http://vpn.example.com:8080). - Set Expected HTTP status to
200. - Set Check interval to
2 minutes. - Click Save.
For a TCP proxy (e.g. SSH or database):
- Add Monitor →
TCP Port. - Host:
<your-frps-host>, Port:<exposed-port>. - Set Check interval to
2 minutes. - Click Save.
These endpoint checks catch two distinct failure modes:
- frps failure: the server is down and no connections are accepted.
- frpc disconnection: the server is running but the client has disconnected, so frps cannot forward traffic.
A proxied-endpoint failure with a healthy frps dashboard (Step 1) tells you that frpc has lost its tunnel — useful for distinguishing server-side from client-side failures.
Step 3: Poll the frps Admin API
frp exposes a REST API on the frps dashboard port that provides detailed metrics about running proxies and their connection state. This is the most precise health signal for frp's internal state.
GET http://<your-frps-host>:7500/api/serverinfo
Authorization: Basic <base64(admin:password)>
A healthy response:
{
"version": "0.55.1",
"bindPort": 7000,
"totalTrafficIn": 1024000,
"totalTrafficOut": 512000,
"curConns": 3,
"clientCounts": 2,
"proxyTypeCounts": {
"http": 2,
"tcp": 1
}
}
Key fields to watch:
clientCounts— number of connected frpc clients. Drop to0means all clients have disconnected.curConns— active connections through proxies.proxyTypeCounts— verify expected proxy types are registered.
Monitor with Vigilmon:
- Add Monitor →
HTTP / HTTPS. - URL:
http://<your-frps-host>:7500/api/serverinfo. - Add Basic Auth with your dashboard credentials.
- Set Expected body contains to
"version". - Set Check interval to
2 minutes. - Click Save.
For a more targeted check, assert on "clientCounts" being non-zero — though Vigilmon's body assertion is a string match, so pair this with the endpoint check in Step 2 for a complete picture.
Step 4: Monitor Individual Proxy Status
The frps API exposes per-proxy status at /api/proxy/{type}:
GET http://<your-frps-host>:7500/api/proxy/http
GET http://<your-frps-host>:7500/api/proxy/tcp
These endpoints return each proxy's status field (online or offline):
{
"proxies": [
{
"name": "web-app",
"type": "http",
"status": "online",
"todayTrafficIn": 204800,
"curConns": 1,
"clientVersion": "0.55.1"
}
]
}
To monitor for offline proxies:
- Add Monitor →
HTTP / HTTPS. - URL:
http://<your-frps-host>:7500/api/proxy/http. - Add Basic Auth.
- Set Expected body contains to
"status":"online". - Click Save.
If a proxy goes offline (client disconnected), the response stops containing "status":"online" and Vigilmon alerts. Create one monitor per proxy type you run.
Step 5: Monitor the frps Port
The frps bind port (commonly 7000) is where frpc clients connect. Monitoring this port with TCP confirms the frp server is accepting new client connections — useful for catching cases where the server is running but has stopped accepting connections due to a configuration error or port conflict.
- Add Monitor →
TCP Port. - Host:
<your-frps-host>, Port:7000(or your configuredbindPort). - Set Check interval to
2 minutes. - Click Save.
Step 6: Monitor SSL Certificate Expiry
If you run the frps dashboard or proxied HTTPS services behind TLS:
- Add Monitor →
SSL Certificate. - Enter the domain:
https://frp.example.comor the domain of your proxied service. - Set Alert when certificate expires in less than
30 days. - Click Save.
frp itself does not manage certificates — TLS termination happens at your reverse proxy (nginx, Caddy, Traefik). If you use frp's native HTTPS proxy type, the origin certificate is exposed through the tunnel. Monitor the public hostname to catch expiry regardless of where TLS terminates.
Step 7: Configure Alert Channels
- Go to Alert Channels in Vigilmon and configure email, Slack, PagerDuty, or webhook.
- For proxied endpoint monitors, set Consecutive failures before alert to
1— a single failed check on a proxied service is significant because frp reconnects quickly and persistent failures indicate genuine problems. - For the dashboard and admin API monitors, use
2consecutive failures to absorb frps restarts. - Add Maintenance windows during frp version upgrades, which require simultaneous frps and frpc restarts.
Going Further
- frpc client monitoring: On the frpc client host, monitor the local admin API at
http://127.0.0.1:7400/api/statusto check the client-side connection state. This pairs with frps monitoring to isolate client vs. server failures. - Multiple frpc clients: If multiple clients connect to the same frps, monitor the
clientCountsfield from Step 3 and alert when it drops below your expected minimum. - Custom domains: For frp HTTP proxies using custom domain routing (
customDomainsin frpc config), add a separate Vigilmon check for each custom domain — the frps dashboard won't catch domain-level routing failures. - Traffic anomaly detection: Vigilmon's response time charts can surface latency spikes in proxied endpoints — an early warning for frpc connection instability before the proxy goes fully offline.
With Vigilmon watching the frps dashboard, proxied endpoints, admin API, and bind port, you'll know the moment your frp infrastructure degrades — from a crashed server to a disconnected client tunnel.