This troubleshooting CSDN page collects the situations where Cisilino Site Defense Network can cause you trouble, with the fix for each one. You’ll need it if you’ve locked yourself out, if the site responds with a 500 error, or if a user can no longer publish. The answers are organised as frequently asked questions.
Troubleshooting CSDN: where to start
Before hunting for the exact answer, run through this checklist.
- Can you still open
wp-admin? If so, almost everything can be fixed from the plugin’s Settings page. - Read the notices at the top. The plugin explains the outcome of its actions in coloured boxes.
- Remember the last thing you changed: a hardening rule, a policy, a limit.
- If there’s a Check now button, use it before guessing.
- If you can no longer get into the site, get your FTP access or the hosting’s file manager ready.
Logins and blocks
I’ve locked myself out: what do I do?
If you still have access to WordPress, for example from your phone on mobile data, open the Blocked IPs tab. Find your IP and press Unblock. If your IP isn’t listed but you’re still blocked (which can come from the optional security list), go to the General tab, “Local IP overrides” section: enter the IP, choose “Always unblock (unban)” and press Save override. Then, in the General tab, press Add to whitelist.
If you’re blocked from the site too, and see a 403 error, log in via FTP and open .htaccess. Remove the line with your IP, or the whole block between # BEGIN Cisilino Site Defense Network and # END Cisilino Site Defense Network.
Warning: the manual edit is temporary. The same source will rewrite the block at the next event: a failed login, a sync, or the 15-minute round. As soon as you’re back in, use Unblock and the whitelist.
Why didn’t the whitelist unblock me?
The whitelist only stops failed logins from being counted. It doesn’t remove blocks already in place. To remove a block you need Unblock, which creates a permanent unblock override on this site.
A legitimate user has been blocked
The attempts counter is cumulative per IP and never resets on its own. Even scattered mistakes over weeks can reach the threshold, which defaults to 10. Unblock the IP and whitelist it, or raise the threshold in Remote settings, where the field is called “Local block threshold (failed attempts)”.
An IP’s block never ends
A local block doesn’t expire. A manual block expires after the chosen duration, from 1 hour to 7 days. If you chose “Permanent (until you remove it)”, it doesn’t expire. A block received from the panel disappears once the panel removes it from the list. A timed unblock, once it expires, brings the block back if the original source is still there. For a definitive unblock use Unblock, which is permanent.
Blocks look odd behind a proxy or a CDN
The plugin reads the IP only from REMOTE_ADDR and ignores the X-Forwarded-For header, because it can be forged. Look at the line “Your current IP is …” under the IP address field in the General tab. If it isn’t your public IP, the plugin is seeing the proxy’s address. In that case, avoid blocking or whitelisting that address until you’ve sorted it out with whoever manages the proxy.
Errors after the .htaccess rules
This part of troubleshooting CSDN covers rules written to the server’s own file.
The site shows a 500 error after saving the hardening rules
The plugin makes no copy of .htaccess and doesn’t check the syntax after writing it. An error, or a rule your server doesn’t accept, shows up straight away as a 500 error.
- Log in via FTP or the file manager.
- Make a copy of
.htaccess. - Delete the block between
# BEGIN Cisilino Site Defense Network - Hardeningand# END Cisilino Site Defense Network - Hardening. - Reload the site, then correct the settings in the Hardening / IDS tab.
The hardening block is only rewritten when you save that tab or reactivate the plugin, not by the 15-minute round. Your manual fix therefore stays in place.
I wrote a custom path and the whole site gives a 403
In the custom paths box, every line is literal text, with no wildcards. The rule blocks any address containing that string. Writing / or wp blocks everything, including wp-admin. Remove the hardening block via FTP, as above. Then, in the Hardening / IDS tab, fix or empty the “Custom paths to block” box and save. If you don’t fix it, a new save or a plugin reactivation will rewrite the rule, and the site will go back to giving a 403.
You see “Settings saved, but writing to .htaccess failed”
The .htaccess file isn’t writable: check the permissions. The rules in that block aren’t active. The two switches that act in PHP, meaning XML-RPC and ?author=N, stay active regardless.
The test says the PHP block in uploads doesn’t work
In the Test tab, the “Check PHP execution block in uploads” box reports whether the test file was executed. Check that your hosting allows .htaccess in that folder, and that there’s no more specific <Directory> block. On nginx the rules have no effect. The rule only covers the standard uploads folder.
A plugin or the theme has stopped working
Switch off the last rule you turned on and save. The most common cases: blocking PHP in uploads breaks plugins that write PHP files there; disabling XML-RPC stops remote apps and functions; blocking executable uploads also rejects files such as .svg.
Users, authors and visitors
An author can no longer publish: “your account is suspended”
Rate limiting has seen too much content created too quickly. By default the limit is 150 items in 300 seconds, with a 3600-second suspension. From the Rate limiting tab, in the suspended users table, press Revoke suspension. Otherwise, wait for it to expire.
Switching off “Rate limit active” doesn’t remove a suspension already under way. Before a large import, raise the limit N or switch off the cap.
A visitor sees “Too many submissions”
A guest has sent too many comments or forms too quickly: more than 2 in 60 seconds by default, with a 3600-second block. The block is by IP, so it can hit several people in the same office. Raise the N value in the visitors section. There’s no list of exceptions.
I can’t create an editor or administrator user
That’s intentional. The default User registration policy is “Low-privilege roles only”, and it makes no exception, not even for you. Switch temporarily to “No restriction”, create the user, then switch back. With “No registration (exclusive)” nobody can create users. Also check the default role under Settings > General in WordPress: if it’s a forbidden role, registrations are rejected.
Connecting to the panel
The panel connection doesn’t show
The status is in the “Panel connection status:” box at the top of the Remote settings tab. If the box is missing, the fields were incomplete: you need the Customer code, the API key and the Panel URL. After “Save and verify connection” no separate banner appears.
- “Panel URL not secure: https is required …”: the address must start with
https. The plugin also refuses to save an http URL. - “Authentication rejected by the panel: customer_code or API key incorrect.”: double-check both values.
- “Unable to reach the panel: …”: a network, DNS or certificate problem.
- “Invalid response from the panel (not JSON).”: the address doesn’t point to the right panel.
If the panel doesn’t respond, local protection carries on and the queued data is sent on the next round. The plugin works even without the panel.
Activity isn’t reaching the panel
In the Activity log tab, look at the diagnostics table and the “awaiting delivery to the panel” row. Press Try sending now: the result appears in the diagnostics. The row cap, 500 by default, deletes the oldest ones even if they haven’t been delivered.
Debug log, integrity and headers
The debug log won’t turn on
There are two possible messages. “the uploads folder is not writable”: fix the permissions on uploads. “the files in its folder appear reachable from the internet”: probably a server with no .htaccess, such as nginx. Block access to the csdn-debug-* folder in the server configuration and try again. If the log stopped because of the 200 MB cap, download or delete the files and turn it back on.
Integrity says “the plugin’s files do not match”
If you’ve edited a plugin file by hand, that’s normal. Otherwise, treat the site as potentially compromised: reinstall the plugin from a trusted copy and check the rest. If the message says there’s no reference at all, reactivate the plugin to take a new snapshot.
HSTS won’t turn on, or won’t turn off
To turn it on you must open the plugin’s settings over https, otherwise you’ll see “HSTS was NOT activated”. Always save from an https page. Unticking the box stops the header being sent, but browsers that already received it will remember it for a long time.
If you can’t find the answer
If this troubleshooting CSDN page isn’t enough, turn on the debug log, reproduce the problem and read the entry. Then open a discussion on the plugin’s support forum: it’s the place to get help and see problems already reported. Don’t paste server paths or sensitive data.
Previous chapter: Debug log: PHP errors in their own file. Next chapter: Deactivation, uninstallation and personal data. For the index: the CSDN manual.
Leave a Reply