Getting straight to the point
If you run a website or manage servers, you already know that a single misbehaving tool can stop a site or email workflow cold. Below I walk you through the frequent problems people face with hosting tools and what to do about them , in plain terms, with actionable checks and fixes you can try right away. Expect practical tips for control panels, ssh, ftp, DNS, ssl, databases, email and backups, plus how to tell when the issue is on your side versus the host’s.
Control panels (cpanel, plesk) , common headaches and fixes
Control panels simplify server tasks but when they break they can block everything from email to dns changes. Typical symptoms are a blank page, login failures, slow response, or specific features failing (backups, SSL installers). First, check server resources: if the machine is out of disk space, panels often stop working. Run a disk check (ssh) with df -h and clear old backups or logs. Next, review the panel service status. For cpanel/whm you might use systemctl status cpsrvd to see if the service is running; restarting it often resolves transient issues: systemctl restart cpsrvd. If the panel shows php errors or blank screens, check the panel error log (paths vary by panel) and verify PHP versions and memory limits. For permission-related failures, confirm ownership of panel files and that key directories are writable. When a panel upgrade fails, consult vendor logs and consider rolling back to a snapshot if available.
Quick checklist for control panel problems
- Check disk space:
df -h. Free up space if needed. - Restart panel services: e.g.,
systemctl restart cpsrvd. - Review panel logs for specific errors and Google the exact message.
- Verify PHP and database services used by the panel are running.
- Contact support if the panel upgrade corrupted configuration files or the control plane is inaccessible.
SSH and remote shell issues , getting locked out and how to recover
SSH problems are often the scariest because they prevent troubleshooting. Common cases: connection refused, authentication failures, or timeouts. Start with network checks: can you ping the server? If not, the server may be down or the network blocking your IP. If you see “Connection refused,” the SSH daemon might be down; check it with systemctl status sshd (or sshd name on some systems). For authentication errors, confirm your key permissions , SSH will refuse keys with loose permissions, so ensure private keys are chmod 600 and the ~/.ssh directory is chmod 700. If password login was disabled and keys are missing, many hosts offer a web-based console or rescue mode you can use to add keys or fix /etc/ssh/sshd_config. If you get dropped sessions or timeouts, check for network packet loss, CPU spikes on the server, or aggressive idle-time disconnects in client or server configs.
SSH fixes you can apply
- Verify service:
systemctl status sshd, restart if needed. - Check key permissions: private key =
chmod 600, ~/.ssh =chmod 700. - inspect
/var/log/auth.logor/var/log/securefor authentication failures. - Use the host’s web console or rescue mode to restore access if keys/passwords are broken.
FTP/sftp problems , transfers failing or logging in but no files
FTP problems often stem from passive/active mode mismatches, firewall rules blocking ports, incorrect home directory permissions, or user chroot issues. If SFTP (SSH-based) works but FTP doesn’t, your FTP daemon or passive port range might be blocked. For classic FTP, open ports 20 and 21 and set a passive port range in the ftp server config, then add firewall rules accordingly. For permission issues where files exist but can’t be seen via FTP, check file ownership and group membership; many web apps require files to be owned by the web server user (www-data, apache, etc.). If you rely on SFTP, prefer it over FTP because it encrypts credentials; SFTP problems are usually solved by fixing SSH permissions or the user’s shell.
Common FTP/SFTP troubleshooting steps
- Try SFTP first (same port as SSH):
sftp user@host. - Check firewall for ports 20, 21 and configured passive range.
- Verify user’s home directory and permissions (ownership, setgid bits, chroot).
- Check FTP server logs for connection or permission errors.
DNS issues , wrong records, propagation and caching
DNS complaints show up as unreachable sites, email delivery failures, or SSL host mismatch. The most common problems are accidentally changed records (A, cname, MX), incorrect TTL expectations, or registrar misconfiguration. Start by checking the authoritative records with tools like dig or online checkers. Look for mismatches between registrar nameservers and the records you expect. If you’ve updated an a record and the change isn’t visible, remember that propagation is influenced by TTL and caching , some resolvers will ignore low TTL values. For email, ensure MX records point to the correct host and that SPF/DKIM/DMARC records are present. If you moved hosting providers, verify the nameserver delegation at your registrar; if those are wrong, nothing else will work.
DNS troubleshooting quick list
- Use
dig @ns1.example.com example.com ANYto query authoritative servers. - Confirm registrar nameservers match your DNS host configuration.
- Check MX records and SPF/DKIM entries for email issues.
- Allow TTL to expire or reduce TTL before planned changes for faster updates.
SSL/tls headaches , expirations, mismatches and renewals
Browsers warn about SSL when certificates expire or don’t match the domain. For Let’s Encrypt, automated renewals sometimes fail because the ACME challenge can’t reach your server (port 80 blocked) or the webroot path is incorrect. Check certificate expiry with openssl s_client -connect host:443 or online SSL checkers. If renewal fails, run a dry run locally with certbot renew --dry-run to see errors. For mismatched hostnames, verify the certificate covers both www and non-www as needed, or use Subject Alternative Names (SANs). When a new certificate is installed but clients see the old one, it may be due to a load balancer or CDN caching; update certs on every layer and restart services.
SSL/TLS fixes
- Check expiry:
openssl s_client -showcerts -connect yoursite:443. - Ensure ACME challenges can reach port 80 (HTTP) and that webroot paths are correct.
- Renew with Certbot and check webserver config reload:
certbot renew --post-hook "systemctl reload nginx". - Update certificates on CDNs/load balancers too, then clear caches.
Databases (mysql/MariaDB/Postgres) , connection errors and slow queries
Database problems show as “error establishing a database connection”, timeouts, or sluggish sites. Start by confirming the database service is running and accepting connections. Locally test with the same credentials your app uses. If you see “Too many connections,” raise the max connections or optimize queries and connection pooling. Corrupt tables can cause errors; for MyISAM run myisamchk and for InnoDB check the error log and consider running an InnoDB recovery mode. Slow sites can also be caused by missing indexes , use slow query logs to find culprits and add indexes where appropriate. Always make backups before attempting repairs.
Database troubleshooting checklist
- Confirm service:
systemctl status mysqlorpostgresql. - Test connection locally with the same credentials used by the app.
- Inspect slow query logs and add indexes for frequent full-table scans.
- When tables are corrupt, run appropriate repair tools and restore from backup if needed.
Email delivery and inbox problems
Email issues range from bounces to being marked as spam. First, check mail server logs (postfix, Exim, Sendmail) to see why delivery failed. If outbound mail is blocked, many cloud providers block smtp port 25 , use your provider’s SMTP relay or a third-party transactional email service (SendGrid, Mailgun). For delivery to inbox problems, ensure you have SPF, DKIM and DMARC records set correctly and that your PTR (reverse dns) is set for your IP. If users can’t receive mail, confirm mailbox quotas and storage; full maildirs will reject new messages. For login problems, check authentication backends (local accounts vs. LDAP) and reset passwords when necessary.
Email troubleshooting tips
- Read mail logs for specific bounce messages and codes.
- Verify SPF/DKIM/DMARC and ptr records to improve deliverability.
- Confirm port availability (25, 587, 465) and use authenticated submission on 587.
- Consider an external SMTP relay if your host blocks port 25.
Backups and restores , they look simple until you need one
Backups fail silently if you don’t verify them. Always test restores on a staging server. Common issues include missing databases in backups, permission errors while archiving, or backups growing until disk fills. Use retention policies and incremental backups to save space. Automated backup tools can break after updates; monitor backup logs daily and set alerts for failures. If you need to restore, follow a documented restore plan: stop affected services, restore files and databases, fix ownership and permissions, then bring services back up while testing functionality.
Backup best practices
- Automate backups and monitor success logs.
- Keep off-site copies (object storage, another region).
- Test restores periodically on a staging environment.
- Document a clear restore checklist to minimize downtime during recovery.
When to call hosting support
You can fix many problems yourself, but call support when the issue involves hardware failure, hypervisor/network outages, control plane access you don’t have, or if your changes risk breaking production and you lack snapshots. Also contact support when the host’s managed services (managed database, load balancer, cdn) are the obvious source of trouble. When opening a ticket, provide clear steps to reproduce, relevant log excerpts, timestamps, and any recent changes you made , it speeds up diagnosis.
Final tips to reduce recurring issues
Prevent problems by automating health checks, keeping systems patched, using monitoring and alerting tools, and maintaining clear runbooks for common recovery steps. Use version control and infrastructure-as-code for server configs so you can revert changes quickly. Schedule maintenance during low-traffic windows and lower TTLs before planned DNS changes. These small practices cut the time you spend firefighting and give you clearer, faster fixes when things do break.
Summary
Most hosting tool problems are caused by resource exhaustion, permission mismatches, network rules, expired certificates, or configuration drift. Work methodically: check service status, read logs, verify permissions and network rules, and test fixes in a safe environment. Keep backups and monitor your systems so you catch issues early, and reach out to host support when the problem involves infrastructure you can’t access.
FAQs
Q: My site shows “Error establishing a database connection” , what should I check first?
A: Verify the database service is running, check the app’s DB credentials, test a local connection using those credentials, and inspect database logs for errors like “Too many connections” or corrupt tables.
Q: How do I fix “Connection refused” when trying to SSH?
A: Confirm the server is reachable over the network, then check that the SSH daemon is running (systemctl status sshd). If the service is down, restart it. Use the host’s console or rescue mode if you cannot access SSH to repair configs.
Q: My SSL renewal failed with Let’s Encrypt , what’s the common cause?
A: The most common cause is the ACME challenge being unreachable (port 80 blocked) or incorrect webroot. Check HTTP access, run certbot renew --dry-run to see the error, and ensure any CDN or proxy forwards the challenge correctly.
Q: DNS changes are not visible , how long should I wait?
A: dns propagation depends on TTL and caches. Some changes show in minutes, others take hours. If your TTL was high, you may need to wait until it expires. Use dig against authoritative nameservers to confirm the source record updated.
Q: When should I restore from backup versus repair the live system?
A: Restore from backup when corruption or data loss affects core data and repairs are risky or incomplete. Use a repair if only a small part is broken and you can fix it without losing recent changes. Always weigh downtime and data loss risk before choosing.
