Not answered here? Write to support@ofuyuan.com.
No. This is a hard design rule: licensing only gates the supply of new data (the threat address database, OTA) and the deeper views. Detection and blocking never stop over a licensing problem, and the thresholds you set stay in force — expiry does not change detection, only whether you can still read and adjust it. The way out of a false positive (unblocking, the whitelist) is free forever, and attack notifications still go out. Nor is the host unbound for having lapsed: renew and supply resumes immediately, with nothing to reassign.
Cancel the ones you no longer need; each lapses on its own expiry date and works normally until then, with no refund for the current term. Because every subscription expires on its own date, you can drop some and keep others.
Usually not. Free-tier detection and blocking are complete. The main reason single-server users upgrade is automatic threat address database updates.
The host's own interface addresses, the private subnet each interface sits on, and 192.168.0.0/16 are whitelisted automatically and never blocked. The public address you connect from is not — if it behaves like an attacker (for example, repeated wrong SSH passwords), it can be blocked like any other. Add the public IPs of your office or home to the whitelist up front.
If it happens: most blocks expire (by default 7 days the first time, then 30 and 180). An address blocked again and again on evidence the server itself produced (wrong SSH passwords, for example) becomes permanent from the fourth time, and blocks you add by hand in the console are permanent too; those need unblocking by hand. To unblock, connect from another network (a phone hotspot, say) and unblock the address in the console's block list, or run sudo svrguard unblock -config /etc/svrguard/svrguard.ini <your IP> on the host. Unblocking and the whitelist are always free; no subscription needed.
Full refund within 14 days of your first purchase; after that you cancel instead and the service runs to its expiry date. See the Refund Policy.
Upgrading does not require removing it — on an upgrade the firewall rules stay in the kernel and keep blocking, and your settings and data are kept. This is about actually clicking remove: the firewall rules are cleared (left behind, the host would go on dropping several hundred addresses with nothing left that could list or undo them); the subscription on this host is handed back to your account and can be assigned to another host; and your settings and database are copied to your NAS storage first (for example /volume1/SvrGuard-backup) and restored automatically when you install again, with the path printed as it goes.
⚠️ One case to check first: if the subscription on this host has been cancelled but has not yet expired, it cannot be assigned back once handed in, and the remaining paid period would lose Pro supply. Do not remove it in that case — let it run to its expiry date.
No. SvrGuard analyses this host's own logs; logs written by services inside containers are outside what it reads. That does not leave containers unprotected — blocks are written into the host's firewall, so a source already blocked cannot reach a service in a container either, including the ones the threat address database brings in from other hosts. The difference is discovery: an attacker that appears only in a container's logs is not visible to us, so it will not produce a new block.
It depends on whose address ends up in the log. A reverse proxy makes every line of the web log carry the proxy's own address — those lines are real traffic, but they all point at one internal address, and that address is never blocked, so web detection on that host produces effectively nothing. We do not read X-Forwarded-For or headers like it: a header is written by the other end of the connection, so blocking on it would let an attacker choose who we block, and the one blocked would be an innocent third party — worse than not detecting at all. The fix is in the web server's configuration: have it record the visitor's address (Apache's mod_remoteip, nginx's real_ip).
⚠️ Only one case is detectable. When the proxy uses a private-range address, the console raises a banner with the counts and the proportion behind it. When the proxy or CDN uses a public address we cannot detect it, and we deliberately do not guess — "a handful of public addresses account for almost every request" is the same shape as "one attacker is hammering this host", and the second is exactly when detection must work. ⛔ So the absence of a banner does not mean the addresses in your logs are usable. To be certain, look at the first field of your access log and check whether it is the visitor's address. SSH and FTP detection is unaffected either way; those read the authentication log.
Through the configuration file. Anything the console can set, the file can set too — this route is for hosts no browser can reach. Where the file lives, what goes in it, how to restart afterwards and how to confirm the change took effect are all on the Settings page.
That is Pro's threat address database. Of the attackers a host identifies, only evidence ordinary use cannot produce (asking for secret files, probing sensitive paths, injection attacks, SSH brute force) goes into the threat address database; the list is reviewed by hand each day before it is published, then distributed to the other hosts and written into the kernel firewall, so you do not have to wait for the same attacker to reach you first. It complements local detection rather than replacing it: local detection finds new attackers, the threat address database keeps out the ones already confirmed elsewhere. When the block list nears its capacity limit, what this host detected itself always comes first; the threat address database gets the remaining room.
