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.
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 coordinated protection 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.
That is Pro's coordinated protection. An attacker identified on any one host is collected into the threat address database, distributed to the others 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, coordinated protection keeps the ones already confirmed elsewhere out in front. When the block list nears its capacity limit, the most recent entries come first; only when recency and severity are equal does an address this host gathered itself take priority.
