Almost as soon as you deploy a server on the internet, it is under attack.

Within seconds, automated bots begin scanning your ports and hammering your SSH login. If you’re using the default settings on your server, then you are more likely to get compromised.

While most cloud providers offer a clean slate, those default configurations are built for convenience, not combat. To truly protect your data, you need to follow industry-standard Linux server security best practices.

Through this guide, you will have a detailed roadmap to secure your VPS with enterprise-grade security. 

Why a Fresh Linux VPS Is a Target for Hackers

As soon as your cloud provider assigns a public IPv4 address to your server, the clock starts. Security researchers and malicious botnets continuously scan the entire IPv4 address space using tools such as Shodan, Censys, and Zmap.

Honeypot data consistently shows that a new, exposed Linux server will experience its first automated SSH login attempt within 3 to 5 minutes of going live.

If you leave default settings intact, it isn’t a matter of if you get breached, but when. If you don’t protect your server, an automated script will root your server, deploy a crypto-mining payload, and potentially leave you with a thousand-dollar cloud compute bill overnight.

What Does the “Attack Surface” Mean?

The “attack surface” is the exact combination of open ports, default configurations, and predictable patterns your server exposes to the internet. A fresh VPS usually has:

• Port 22 open to the world: The universal beacon for SSH brute-force scripts.
• Root login enabled: Giving attackers the ultimate username; they only need to guess the password.
• Password authentication is enabled, allowing unlimited dictionary attacks against your login prompt.

If you provision your servers through a control panel like RunCloud, much of this attack surface is already minimized for you. But if you are managing a bare-metal VPS yourself, run the commands below to manually lock it down.

However, any one single measure won’t be enough to protect your server; that’s why we recommend following the “Swiss Cheese Model of Security”.

Suggested read: 10 Security Tips to Secure VPS Server in 2025 [Ultimate Guide] 

The Swiss Cheese Model of Security

This model is built on the principle that security should never rely on a single control, as even the best defense has holes, or “slices” of weakness. 

In this model, each layer of security (like disabling root login, configuring UFW, enabling Fail2Ban, etc.) is represented by a slice of Swiss cheese. Each slice has holes representing vulnerabilities, misconfigurations, or human error.

• A single slice (one defense) is easily penetrated if an attacker’s exploit aligns with the hole in that single layer.
• Multiple slices stacked together provide defense-in-depth. While the holes in the first slice (e.g., a custom SSH port) might align with the threat, the second slice (e.g., SSH key authentication) or the third slice (e.g., Fail2Ban) is highly unlikely to have a hole in the exact same spot.

By stacking all 11 steps in this guide, we can ensure that even if one defense fails, the next layer (or the layer after that) will stop the threat, preventing it from reaching your core application.

Suggested read: 5 Ways to Fix the SSH Connection Refused Error [SOLVED] 

How to Harden a Linux Server

Follow the steps below to protect your Linux server on the internet:

Step 1: Disable Root Login and Create a Sudo User

Performing regular maintenance activities on your server as the root user is dangerous – a single typo can destroy your system.

To protect your system, we recommend creating an unprivileged user and granting it administrative rights via sudo.

Connect to your VPS as root, then run:

# Replace 'sysadmin' with your preferred username
adduser sysadmin

You will be prompted to set a password. Make it strong, even though we will disable password logins shortly. Skip the contact information prompts by hitting Enter.

Next, add your new user to the sudo group so you can execute administrative commands:

usermod -aG sudo sysadmin

Verify it works before logging out. Switch to your new user and test sudo:

su - sysadmin
sudo ls -la /root

If you are prompted for your password and can successfully see the contents of the root directory, your sudo user is ready.

With RunCloud, you can manage users and permissions for your Linux server directly from the web dashboard, without SSHing into the server. 

Step 2: Switch to SSH Key Authentication and Disable Password Login

A secure password is hard to remember, and a weak password can be cracked immediately. That’s why all cybersecurity experts agree that cryptographic keys are a better replacement for your username/password based logins.

In this step, we are going to replace password authentication with an ed25519 SSH key pair (which is faster and more secure than older RSA keys).

Generate your key pair locally

Do not run this on your VPS. Open a new terminal on your local computer (your Mac, Windows, or local Linux machine):

ssh-keygen -t ed25519 -C "[email protected]"

Hit Enter to save the key to the default location (~/.ssh/id_ed25519). When prompted, you can set a strong passphrase to encrypt the key on your local disk or leave it blank if you don’t want to encrypt it.

Copy the public key and lock down the sshd_config

Still on your local computer, copy the public key to your VPS, targeting your new sudo user:

ssh-copy-id sysadmin@YOUR_VPS_IP

Now, go back to the terminal window connected to your VPS. It’s time to edit the SSH daemon configuration to disable password logins and root access permanently.

sudo nano /etc/ssh/sshd_config

Find the following lines, uncomment them (remove the #), and change their values to match these exactly:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Save and exit (CTRL+O, Enter, CTRL+X). Do not restart the SSH service just yet; we are going to change the port in the next step.

Note: RunCloud users can add SSH keys to their servers simply by pasting their public key into the RunCloud dashboard, no nano or config editing required.

Step 3: Change the Default SSH Port

Most automated scripts scan for and try to exploit port 22. Moving SSH to a non-standard high port (between 1024 and 65535) won’t stop a targeted attack, but it drops botnet noise by 99%, keeping your auth logs clean and saving CPU cycles.

Open the SSH config file again:

sudo nano /etc/ssh/sshd_config

Find the line that says #Port 22. Uncomment it and change it to your desired port. For this example, we will use 52222:

Port 52222

Save and exit.

Warning: DO NOT restart SSH until we configure the firewall in Step 4, or you will permanently lock yourself out.

Step 4: Configure UFW to Allow Only What You Need

Ubuntu and Debian servers use UFW (Uncomplicated Firewall) to manage network connections. To protect your server, we recommend setting a default-deny policy for incoming traffic, allowing outgoing traffic, and explicitly opening only the ports we need.

Run the following commands on your VPS:

# Deny all incoming traffic by default
sudo ufw default deny incoming


# Allow all outgoing traffic by default
sudo ufw default allow outgoing


# Allow your NEW custom SSH port (crucial!)
sudo ufw allow 52222/tcp


# Allow HTTP and HTTPS if you are hosting web apps
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Review your staged rules:

sudo ufw show added

If everything looks correct, you can enable the firewall by running the following command:

sudo ufw enable

Once the firewall is enabled, any new traffic entering or leaving your server will be inspected and filtered according to the rules we configured above. If any application has already established a connection, it won’t be terminated, but if the application attempts to establish a new connection, it will be blocked by the firewall. 

Now that the firewall allows traffic on your custom port, we can safely apply the SSH changes by running the following command:

sudo systemctl restart ssh

Testing phase: DO NOT CLOSE your current terminal session. Open a new terminal on your local machine and test your new setup:

ssh -p 52222 sysadmin@YOUR_VPS_IP

If you successfully connect using your SSH key, you can close the original root session.

Note: If configuring firewalls over CLI makes you nervous, RunCloud’s Firewall Manager lets you set, preview, and deploy port rules and IP whitelists directly from the dashboard without touching the terminal.

Suggested read: Enable Zero-Trust SSH with Cloudflare on Windows, Mac, Linux, and ChromeOS 

Step 5: Install Fail2Ban to Block Brute-Force Attacks

Now that we have changed the SSH port and disabled password authentication, the server is relatively secure, but automated bots will still try to break in by sending random login attempts with incorrect credentials.

Fail2Ban monitors your log files and dynamically updates your firewall to block IP addresses that show malicious behavior.

To configure this on your Linux server, you can install the Fail2Ban package using the following command:

sudo apt update && sudo apt install fail2ban -y

After installing it, you need to create a set of rules (called “jails”) for your server. We strongly recommend that you don’t edit the default jail.conf file, as package updates will overwrite it. Instead, you should copy it to create a new file called jail.local. You can do this on a Linux server using the following command:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

After creating the file, you can edit your local configuration:

sudo nano /etc/fail2ban/jail.local

Scroll down to the [sshd] block. You need to tell Fail2Ban that you are using a custom port, and explicitly enable the jail. Modify the block to look like this:

[sshd]
enabled = true
port    = 52222
logpath = %(sshd_log)s
backend = %(sshd_backend)s
maxretry = 3
bantime = 1h

Run the following commands to save and exit, then start and enable the service:

sudo systemctl enable fail2ban
sudo systemctl restart fail2ban

After creating the service, you can verify that your SSH jail is active using the following command:

sudo fail2ban-client status sshd

In the screenshot above, we can see the list of IP addresses that Fail2Ban has banned from accessing our server.

By completing these 5 steps, you have eliminated the low-hanging fruit that compromises 95% of fresh Linux setups. 

Note: Getting Fail2Ban thresholds wrong in jail.local often results in banning yourself or failing to trigger on real attacks. That’s why RunCloud ships with Fail2Ban pre-configured for web and SSH traffic. 

Suggested read: How to Use Cloudflare Firewall Rules to Protect Your Web Application 

Step 6: Enable Automatic Security Updates

A hardened server is only secure until the next CVE is published. If you are managing more than one server, you should not want to manually run apt upgrade whenever a vulnerability is discovered in OpenSSL or your kernel. Enable unattended-upgrades to automatically install critical security patches in the background.

To do this, first you need to install the necessary packages using the following command:

sudo apt update && sudo apt install unattended-upgrades apt-listchanges -y

After installing the services, you can enable the service via the interactive prompt:

sudo dpkg-reconfigure -plow unattended-upgrades

Select Yes when prompted to automatically download and install stable updates.

After configuring it, check the configuration file to verify that it has been activated successfully using the following command:

cat /etc/apt/apt.conf.d/20auto-upgrades

When you run the above command, you should see APT::Periodic::Unattended-Upgrade "1"; in the output.

Step 7: Remove Unused Packages and Disable Unnecessary Services

Every service running on your server is a potential entry point for hackers. If you aren’t using a service or application, you can turn it off to protect your server and conserve resources.

To do this, first, we will audit what is actively listening on your server’s network interfaces by using the following command:

sudo ss -tulpn

If you see any services that you don’t want, then you can stop and disable them so they don’t start on reboot:

sudo systemctl stop <name>
sudo systemctl disable <name>

In the above commands, replace the <name> with the actual name of the service that you want to disable. 

Next, purge any orphaned packages and dependencies that came pre-installed on your provider’s OS image but which aren’t needed anymore:

sudo apt autoremove --purge -y

Step 8: Harden Kernel Parameters with sysctl

By default, the Linux kernel uses networking parameters optimized for broad compatibility rather than strict security. When you deploy your server on the internet, it will be constantly bombarded with hundreds of attacks that try to exploit these compatibility features. 

But you can mitigate several types of network attacks (like SYN floods and IP spoofing) by tweaking sysctl.conf. To do this, you can open the configuration file using the following command:

sudo nano /etc/sysctl.conf

In this file, we will disable certain features by appending the following lines to the bottom of the file:

# Protect against SYN flood attacks
net.ipv4.tcp_syncookies = 1


# Ignore ICMP broadcast requests (prevent smurf attacks)
net.ipv4.icmp_echo_ignore_broadcasts = 1


# Disable ICMP redirects (prevent man-in-the-middle routing attacks)
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0


# Log spoofed packets, source routed packets, and redirect packets
net.ipv4.conf.all.log_martians = 1

After editing the file, you can save and exit the file editor (CTRL+O, Enter, CTRL+X). After that, you can apply the changes immediately without rebooting by running the following command:

sudo sysctl -p

Suggested read: 16 Best Linux Distros in 2025 

Step 9: Set Strict File Permissions and Audit User Accounts

If an attacker compromises a system, they will try to either create hidden backdoor users, or leave files with wide-open permissions. There are several steps you can take to ensure this isn’t the case on your server. First, you can audit your user accounts to ensure only root has a User ID (UID) of 0. Run this command to print any user with root-level privileges:

awk -F: '($3 == "0") {print}' /etc/passwd

This should output exactly one line: root:x:0:0:root:/root:/bin/bash. If you see any other user here, then it is possible that your server is compromised.

Next, verify that no users have empty passwords:

sudo awk -F: '($2 == "") {print}' /etc/shadow

This should return no output.

Finally, find and review any world-writable directories (directories anyone can write to) that don’t have the “sticky bit” set (which prevents users from deleting each other’s files):

sudo find / -type d -perm -0002 -a ! -perm -1000 -print 2>/dev/null

If your server is serving multiple websites, then the above command will probably return a long list of directories. You need to review this list and, if you find any rogue directories, investigate them immediately and restrict their permissions using chmod 755.

Step 10: Review Mandatory Access Control (AppArmor and SELinux)

AppArmor (on Ubuntu/Debian) and SELinux (on RHEL/AlmaLinux) are Mandatory Access Control (MAC) systems. They act as a high-level security guard built directly into the Linux kernel. While standard file permissions (chmod) control who can see a file, MAC systems control which specific programs are allowed to do what.

In a standard setup, if a hacker exploits a vulnerability in a web server such as NGINX and gains “root” access, they can theoretically access every file on your server.

With AppArmor or SELinux active, the program is confined to a “sandbox.” Even if NGINX is compromised, the MAC system detects that NGINX is attempting to access sensitive system files (such as/etc/shadow) or execute unauthorized commands. Because that behavior isn’t in the program’s predefined “security profile,” the kernel blocks the action instantly, even if the attacker has root privileges. It effectively limits the “blast radius” of any potential hack.

You can run the following commands to check the configuration of these systems on your server:

• On Ubuntu/Debian (AppArmor):

sudo aa-status

• On RHEL/Alma/Rocky:

sestatus

Manually configuring MAC systems is tricky, and beyond the scope of this article. It requires writing deep-level security profiles that define every single file, port, and network socket a program is allowed to touch. One small mistake in a profile can cause your database to crash or prevent your website from loading, leading to hours of frustrating troubleshooting.

The good news is that if you are using RunCloud, you don’t need to lift a finger.

RunCloud servers are engineered to be secure out of the box. The platform automatically configures and optimizes these security layers during server provisioning. Your server is hardened the moment it connects to the RunCloud panel, allowing you to focus on your applications while RunCloud handles the complex kernel security in the background.

Step 11: Configure Off-Server Backups

Hardening your server reduces the risk of a hack, but it cannot protect you against hardware failure, a data center fire, or an accidental rm -rf / command. Off-server backups ensure that even if your entire VPS is deleted, your business can be restored in minutes.

There are several ways to handle backups, each with its own pros and cons:

1. Disk-Level Snapshots: Taking a full image of your server via your provider (like DigitalOcean or AWS). These are easy but often expensive, and they’re hard to move between providers.
2. Application Plugins: Using WordPress plugins like UpdraftPlus. These are user-friendly, but they can slow down your site because they use your server’s PHP resources to compress files.
3. Manual Scripting: Using Linux tools to manually move data. If you choose to do this manually, you must manage three distinct parts: the database, the files, and the transport. 
   • Security: Manual rclone or script configs often store your Cloud API keys or Database passwords in plaintext on the server. If a hacker gets in, they now have your backup keys too.
   • Resource-Heavy: Compressing large folders (tar) and dumping databases every night causes high CPU and Disk I/O spikes, which can make your website sluggish during the backup window.
   • Reliability: If the script fails, you won’t know until you try to restore and find out that the files are empty.

If you are using RunCloud, you don’t need to deal with any of this.

RunCloud uses Incremental Backups, which is a far superior technology. Instead of zipping your entire site every night (which is slow and uses a lot of disk space), RunCloud only identifies the specific data that changed – and syncs just that.

• Fast & Efficient: Because it only moves “changes,” backups finish in seconds rather than minutes.
• Zero Resource Lag: It doesn’t put a heavy load on your server, keeping your website fast even during a backup.
• Encrypted & Secure: Your S3 or Backblaze credentials are stored in RunCloud’s encrypted vault.
• Backup Notifications: You can configure the Backup script to notify you via Slack/Email/Discord if the backup fails for any reason.
• One-Click Restore: If something goes wrong, you don’t have to remember complex Linux commands. You just click “Restore” in the dashboard, and RunCloud puts everything back exactly where it belongs.

After Action Report

If you have followed all the steps in this article, your server is now locked down and can withstand a variety of internet attacks. But a hardened server isn’t very useful if it doesn’t host anything. The next step is installing your web stack (NGINX/Apache, PHP, MySQL) and provisioning SSL certificates.

Doing this manually means diving right back into the terminal. After hardening, managing NGINX, PHP-FPM, and SSL still requires SSH for every single configuration change, virtual host creation, and certificate renewal.

RunCloud manages your NGINX configuration, PHP-FPM tuning, and Let’s Encrypt SSL deployments entirely from a UI, while fully respecting the hardened SSH and firewall configurations you just put in place. 

While RunCloud simplifies complex server management tasks, it is designed for developers, agencies, and power users who need more than just a basic cPanel replacement. Once your servers are hardened, RunCloud enables you to scale your operations by offering tools for advanced management:

• Multi-Server Management: Easily oversee, update, and manage dozens or hundreds of hardened Linux servers from a single dashboard.
• Team & Role-Based Permissions: Delegate server access to team members or clients without sharing SSH keys or root passwords, thanks to granular control over who can manage applications, databases, or backups.
• API-Driven Control: Integrate server and application management into your custom workflows using the RunCloud API, allowing for automated server provisioning and deployment.

Start using RunCloud today.

Frequently Asked Questions

The post Linux Server Hardening: 11 Steps to Secure a Production VPS appeared first on MASSIVE News.

If you’re running NGINX on a modern server, you’re likely leaving performance on the table by sticking with HTTP/2.

HTTP/3 changes how browsers connect to your server. It reduces latency, improves performance on unstable networks, and can noticeably speed up real-world page loads – especially for mobile users.

The problem is that enabling HTTP/3 on NGINX isn’t straightforward. It requires the right version, specific modules, firewall changes, and careful configuration. One small mistake can stop NGINX from restarting.

In this guide, you’ll learn exactly how to enable HTTP/3 on NGINX step by step – from checking compatibility to verifying that it’s working correctly.

Step-by-Step Instructions for Enabling HTTP/3 on NGINX

Use the steps below to enable and verify HTTP/3 on your Ubuntu server.

Step 1: Ensure You Meet Prerequisites for HTTP/3

Before enabling HTTP/3 (QUIC) on your Ubuntu server, ensure your environment meets the prerequisites. Since HTTP/3 works over UDP rather than TCP, your underlying web server, network firewall, and encryption standards must support it.

NGINX Version Supports HTTP/3

The most important requirement for enabling HTTP/3 is having a compatible NGINX version. According to the official NGINX QUIC documentation, support for QUIC and HTTP/3 was officially introduced in NGINX version 1.25.0. In these newer releases, the required ngx_http_v3_module is included in the official Linux binary packages by default.

How to Check Your Current Version: Run the following command to check your NGINX version and its compiled modules:

nginx -V 2>&1 | grep --color -- --with-http_v3_module

Look for nginx version: nginx/1.25.0 (or higher) and ensure that --with-http_v3_module is present in the configure arguments.

If your Ubuntu repository ships older “stable” releases (like 1.18.x or 1.24.x) that do not include HTTP/3 support out of the box. Then you can install the Mainline version from the official NGINX repositories.

Run the following commands to install the necessary dependencies:

1. Install prerequisite packages:

sudo apt update
sudo apt install curl gnupg2 ca-certificates lsb-release ubuntu-keyring

2. Import the official NGINX GPG signing key:

curl https://nginx.org/keys/nginx_signing.key | gpg --dearmor | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null

3. Add the NGINX Mainline repository for Ubuntu:

echo "deb[signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] 
http://nginx.org/packages/mainline/ubuntu `lsb_release -cs` nginx" 
| sudo tee /etc/apt/sources.list.d/nginx.list

4. Prioritize NGINX packages (APT Pinning): This ensures Ubuntu prioritizes the official NGINX repository over its own default repositories.

echo -e "Package: *nPin: origin nginx.orgnPin-Priority: 900n" | sudo tee /etc/apt/preferences.d/99nginx

5. Install the latest NGINX version:

sudo apt update
sudo apt install nginx

Suggested read: How to Set Up a Hetzner Server with RunCloud 

SSL Certificates are Configured (HTTP/3 Requires TLS 1.3)

Unlike older HTTP versions, where HTTPS was a secondary layer, HTTP/3 inherently requires encryption via QUIC. You cannot run HTTP/3 over unencrypted http:// connections. Additionally, the QUIC protocol mandates the use of TLS 1.3 to enable faster 0-RTT (Zero Round Trip Time) handshakes and better security.

Before proceeding, you must ensure:

1. You have a valid domain name pointing to your Ubuntu server’s IP address.
2. An SSL/TLS Certificate is configured. A free certificate from Let’s Encrypt (using Certbot) is perfect for this.
3. TLS 1.3 is enabled in your config. Verify that your existing NGINX server block contains TLSv1.3 in the ssl_protocols directive.

Your current HTTPS block should look something like this before adding HTTP/3:

server {
    listen 443 ssl;
    server_name example.com;


    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;


    # TLS 1.3 MUST be included for QUIC/HTTP/3 to function
    ssl_protocols TLSv1.2 TLSv1.3;
}

Root or Sudo Access to Edit NGINX Config

Finally, you will need root or sudo access to your Ubuntu server. Upgrading to HTTP/3 requires modifying core NGINX configuration files, tweaking firewall rules, and restarting system services.

Step 2: Open UDP Port 443 on Your Firewall

Unlike HTTP/1.1 and HTTP/2 which rely on TCP, HTTP/3 uses the QUIC protocol, which operates entirely over UDP. If you don’t explicitly open UDP port 443 on your firewall, client requests will never reach your NGINX HTTP/3 listener, and browsers will silently downgrade back to HTTP/2 over TCP.

UFW (Ubuntu)

If you are using Uncomplicated Firewall (UFW), which comes standard on Ubuntu, simply run:

sudo ufw allow 443/udp
sudo ufw reload

iptables

If you manage your firewall directly using iptables, run the following to append the UDP rule:

sudo iptables -A INPUT -p udp --dport 443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

After making the changes, you need to save your iptables rules using netfilter-persistent save or iptables-save, depending on your server setup

Cloud Firewall (Hetzner, GCP, DigitalOcean)

If your server is hosted on a cloud provider, local firewall rules (UFW/iptables) are often overridden or supplemented by cloud-level security groups. The exact steps will vary depending on your cloud provider:

• Hetzner Cloud: Go to your server’s “Firewalls” tab and add an Inbound rule for Protocol: UDP, Port: 443.
• Google Cloud Platform (GCP): Go to VPC Network > Firewall. Create a new ingress rule targeting your instance, select UDP, and specify port 443.
• DigitalOcean: Navigate to Networking > Firewalls. Add an Inbound Rule for Custom UDP on port 443.

Pro Tip: If you are using RunCloud to manage your infrastructure, our official server setup guides for providers like Hetzner and GCP cover this firewall step in great detail.

Step 3: Add the QUIC Listener and HTTP/3 Directives to Your Server Block

Now it’s time to tell NGINX to actually listen for QUIC traffic and advertise HTTP/3 capabilities to the browser.

Open your website’s NGINX configuration file (e.g., sudo nano /etc/nginx/conf.d/example.com.conf or /etc/nginx/sites-available/default).

Here is a complete, copy-paste-ready server block configured for HTTP/3:

server {
    # 1. Standard TCP listener for HTTP/1.1 and HTTP/2 (Fallback)
    listen 443 ssl;
    
    # 2. UDP listener for QUIC and HTTP/3
    listen 443 quic reuseport;


    server_name example.com www.example.com;


    # 3. SSL/TLS Certificates
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;


    # 4. Enable TLS 1.3 (Required for HTTP/3)
    ssl_protocols TLSv1.2 TLSv1.3;


    # 5. Core HTTP/3 Directives
    http3 on;
    quic_retry on;
    ssl_early_data on;


    # 6. Advertise HTTP/3 to clients via the Alt-Svc header
    add_header Alt-Svc 'h3=":443"; ma=86400' always;


    # The rest of your location blocks go here...
    location / {
        try_files $uri $uri/ =404;
    }
}

Each directive below controls a specific part of how HTTP/3 works in NGINX. Here’s what each one does and why it matters.

listen 443 quic reuseport;
Tells NGINX to listen for UDP traffic on port 443 and distributes the processing load across multiple worker processes.

http3 on;
enables the HTTP/3 protocol decoding for the current server block.

ssl_protocols TLSv1.3;
Configures the use of TLS 1.3, the strict encryption standard required by the QUIC protocol.

quic_retry on;
Defends against UDP spoofing attacks by requiring clients to validate their IP address during the handshake.

ssl_early_data on;
Enables 0-RTT (Zero Round Trip Time), allowing returning clients to resume encrypted connections instantly without handshake delays.

add_header Alt-Svc 'h3=":443"; ma=86400' always;
Tells connecting web browsers, “Hey! I support HTTP/3 on port 443, remember this for the next 86,400 seconds (1 day).”

If you host multiple websites (virtual hosts) on the same NGINX server, you need to be careful with the reuseport parameter. You can only define reuseport once per IP and port combination.

For your primary website, use: listen 443 quic reuseport;

For all other websites on the same server, omit reuseport: listen 443 quic; If you put reuseport in multiple server blocks, NGINX will throw an error and refuse to start.

Suggested read: How to Set Up a Google Cloud Server to Host Your Websites 

Step 4: Test and Reload NGINX

Whenever you alter NGINX configurations, you must test the syntax before applying the changes to prevent your live server from crashing.

Run a configuration test to confirm your changes are valid before reloading NGINX:

sudo nginx -t

If the output says nginx: configuration file /etc/nginx/nginx.conf test is successful, apply the changes instantly without dropping active connections by reloading NGINX:

sudo nginx -s reload

Step 5: Verify HTTP/3 Is Active

You can use a web-based testing tool like http3check.net to check your setup is working as expected. Simply type your website’s domain name into the search bar and click “Check”. The tool will attempt a QUIC connection from its own servers and confirm whether UDP port 443 is open, TLS 1.3 is functioning, and your NGINX instance is successfully serving HTTP/3.

Suggested read: How to Fix ERR_SSL_VERSION_or_CIPHER_MISMATCH 

Enable HTTP/3 Without Touching Config via RunCloud

Managing NGINX configurations manually can quickly become a headache, especially as your server scales. One typo in your nginx.conf, forgetting to open a UDP port, or accidentally duplicating the reuseport directive across multiple server blocks can crash your entire web server.

If you have just completed all the manual steps above, you might be wondering: Is there an easier way to do this for my next server?

The answer is ‘yes’, and the solution is RunCloud.

With RunCloud, you can skip the command line entirely, instead enabling HTTP/3 for each web application directly from your dashboard with a single toggle.

Here’s how RunCloud simplifies the process:

• No SSH Required: You never have to log in to your server’s terminal to edit configuration files.
• No reuseport Management: RunCloud’s automated NGINX stack intelligently handles the listen 443 quic reuseport rule across multiple domains. You never have to worry about conflicting server blocks.
• One-Click Toggles: Simply navigate to your Web Application settings, toggle HTTP/3 on, and RunCloud safely reloads your NGINX server in the background.

For more details on how effortlessly this works, check out the official RunCloud documentation on enabling HTTP/3.

Wrapping Up

In this post, we have discussed the steps required to enable HTTP/3 on an NGINX server. As you can see, the manual process requires several intricate steps: checking NGINX versions, configuring firewalls for UDP port 443, and carefully modifying server block directives.

While the benefits of HTTP/3 are worth the effort, manual configuration is tedious and prone to human error. You don’t have to do it this way.

You can completely skip the command line and complex configuration files by using RunCloud.

RunCloud is a server management dashboard for PHP and web applications. It provides a visual interface for configuring firewalls, managing databases, deploying code via Git, and enabling features like HTTP/3 without editing configuration files.

If you want to avoid manual setup and reduce the risk of configuration errors, sign up for RunCloud and enable HTTP/3 in a few clicks.

FAQs

The post How to Enable HTTP/3 on NGINX appeared first on MASSIVE News.

Have you ever encountered the “memory size exhausted” message on your website? If yes, then you’ll probably know that this single issue can bring your entire site to a halt.

If you are seeing this message, don’t panic. It’s one of the most common issues WordPress users face – and is completely fixable.

This fatal error simply means that a script on your site (usually from a plugin or theme) required more server memory (RAM) than your web hosting environment was configured to provide.

In this guide, we will walk you through everything you need to know to solve the “memory size exhausted” problem for good.

You’ll learn how to check your current WordPress memory limit and discover proven methods to increase it, whether by editing the wp-config.php file, the .htaccess file, or the master php.ini file.

Let’s get started!

How to Check Your Current PHP Memory Limit in WordPress

Before you can fix a memory exhausted error, you first need to identify your current limit. There are several ways to do this. 

1. Using the Site Health Tool in the WordPress Dashboard

The easiest and safest way for any user to check the PHP memory limit is directly within the WordPress dashboard. WordPress has a built-in “Site Health” tool that reports your website’s configuration and server environment.

To access it:

• Navigate to your WordPress admin area and go to Tools > Site Health.
• Click on the “Info” tab at the top of the page, which will reveal a series of expandable sections.
• Click on the “Server” dropdown, and you will see a detailed list of your server’s configuration.
• Look for the “PHP memory limit” entry to see the value configured for your site.

Suggested read: How to Fix WordPress High CPU Usage (10 Instant Solutions)

2. Checking PHP Info or Server Configuration Files

If you want more information or can’t access the WordPress dashboard, you can create a phpinfo file. This method queries the server directly and displays the master PHP configuration.

To do this, you just need to create a new file named info.php in your website’s root directory using an FTP client or a file manager, and place the following single line of code inside it:

<?php phpinfo(); ?>

Save the file, then visit yourwebsite.com/info.php in your browser. You will see a detailed page with all PHP settings; search for memory_limit to find the current value.

Suggested read: How to Fix WordPress Stuck in Maintenance Mode? [100% WORKING]

3. Identifying Memory Limit via Hosting Control Panel (cPanel, RunCloud, etc.)

Most modern hosting environments provide a graphical interface to view and manage server settings. In traditional control panels like cPanel, you might find this information under a “MultiPHP INI Editor” or “Select PHP Version” tool. 

On a more powerful platform like RunCloud, this information is even more accessible and transparent. Simply navigate to your Web Application > Settings within the RunCloud dashboard.

Here, you will see your current PHP version and its associated memory limit clearly displayed:

Suggested read: How to Fix WordPress Revisions Not Showing [SOLVED]

How to Fix the WordPress Memory Exhausted Error (7 Proven Methods)

There are several ways to fix the WordPress Memory Exhausted error, ranging from simple configuration file edits to leveraging your hosting control panel. Let’s explore these methods in detail to help you get your WordPress site back on track.

1. Increase PHP Memory Limit via wp-config.php File

This is the standard WordPress method for increasing the memory available to your application. The wp-config.php file contains your site’s base configuration and is located in the root directory of your WordPress installation.

(Before editing, it is recommended that this file be backed up.)

First, you need to open the wp-config.php file either using your FTP client or the RunCloud File Manager. In this file, add the following line of code just before the line that says /* That’s all, stop editing! Happy publishing. */:

define('WP_MEMORY_LIMIT', '256M');

If needed, you can change 256 MB to a higher value, like 512 MB. This command instructs WordPress to override the default PHP memory limit for its own processes.

Suggested read: How to Check Linux CPU Usage or Utilization (5 Ways)

2. Edit the .htaccess File to Raise Memory Limit

If editing wp-config.php doesn’t work, it may be because your hosting provider has locked that setting at the server level. In some Apache servers, you can also edit the .htaccess file, which is also located in your site’s root directory. This file controls server configurations for your specific directory.

Again, ensure you have a backup before proceeding. Open the .htaccess file and add the following line at the very end of the file:

php_value memory_limit 256M

Save the file and check if the error is resolved. 

Suggested read: How to Find the Most Used Disk Space Directories and Files in Linux

3. Modify the php.ini File on Your Server

The php.ini file is the master configuration file for PHP on your server. Modifying this file changes the memory limit for all PHP applications, not just WordPress, which makes it the most powerful method. However, on shared hosting, you typically do not have access to this file, so this method is primarily for users on a VPS or dedicated server where you have root or sudo privileges.

If you have server access, you must first locate the correct php.ini file, as its location varies significantly by Linux distribution and PHP version. For instance, on a server running Ubuntu or Debian with PHP 8.1 and Apache, the path is /etc/php/8.1/apache2/php.ini. If you’re using NGINX with PHP-FPM, the path would instead be /etc/php/8.1/fpm/php.ini. On distributions like CentOS or AlmaLinux, a common location is simply /etc/php.ini.

The most reliable way to find the exact path your web server is using is to check the “Loaded Configuration File” line within a phpinfo() page, as explained above. Once you have located and backed up the correct file, you will find and change the following line:

memory_limit = 256M

Suggested read: The 10 Best PHP Frameworks (Complete Guide)

4. Use the Hosting Control Panel or the RunCloud Dashboard to Increase Memory

The safest and most recommended method for novice users is to use the tools provided by your hosting provider or server management panel. These interfaces are designed to prevent the configuration errors that can occur when editing files manually. Most control panels have a section for managing PHP settings where you can select your domain and choose a new memory limit from a dropdown menu.

RunCloud excels at this, and it provides a dedicated and intuitive control for each web application. From your dashboard, go to Web Application > Settings, where you can easily adjust the PHP memory_limit with a simple input field. 

After you make the necessary changes, you can save the settings without any need for SSH or FTP.

Suggested read: How to Fix WordPress HTTP Error When Uploading Images (Quick Guide)

5. Deactivate Heavy or Poorly Coded Plugins

Sometimes, the problem isn’t the memory limit itself, but a single plugin consuming an excessive amount of resources. A poorly coded plugin or a feature-heavy one (like a page builder or a complex backup solution) can easily trigger a memory error by creating a memory leak or simply by performing a task that is too resource-intensive for your server’s configuration. 

In this case, increasing the memory limit will not solve the issue, and you will need to identify the specific component causing the issue without disrupting your live site.

Instead of resorting to the time-consuming method of deactivating all plugins on your live site, your first step should be to check the server logs. The NGINX error logs, for instance, often contain the exact PHP script path that triggered the fatal error.

Furthermore, a plugin that exhausts memory is frequently a slow-performing one; this is where RunCloud’s built-in slow script monitoring becomes invaluable. It helps you identify scripts that are taking too long to execute and are likely candidates for high memory usage.

Once you have identified a suspect, the safest way to confirm your diagnosis is in a non-production environment. Instead of deactivating plugins on your live site and risking further downtime, use RunCloud’s one-click staging functionality. This creates an identical, isolated copy of your site where you can safely deactivate the suspected plugin and test thoroughly without impacting your visitors. If the error disappears on the staging site, you’ve found your culprit and can proceed with deactivating or replacing it on your live production site.

Suggested read: Everything You Need To Know About the wp-config.php File

6. Optimize Images and Media Files to Reduce Memory Usage

One of the most common reasons for memory exhaustion is uploading large, high-resolution images. When you upload a picture, WordPress doesn’t just store it directly; it uses PHP to process it and create multiple smaller versions (thumbnails). This image processing is a very memory-intensive task, and a large file can easily push PHP past its limit.

To prevent this, always optimize and resize your images before uploading them to WordPress using a tool like Photoshop or an online image compressor. You can also use a WordPress plugin that optimizes images on the fly, but be mindful that the optimization plugin itself will also consume resources. By reducing the initial file size, you significantly decrease the amount of memory needed for processing.

Suggested read: Scaling RAM & CPU Cores – How They Affect WordPress Performance

7. Upgrade Your Hosting Plan for Higher PHP Memory Allocation

If you have tried all the above methods and are still hitting memory limits, especially on a shared hosting plan, it may be time to upgrade. Shared hosting environments place strict, and often low, caps on resources like RAM to ensure stability for all users on the server. No amount of configuration file editing can overcome a hard limit imposed by your provider.

Upgrading to a VPS (Virtual Private Server) gives you dedicated resources and full control over your server environment. With RunCloud managing your VPS, you can easily set your PHP memory limit to 512 MB, 1GB, or whatever your applications require.

Wrapping Up: Best Practices to Prevent the WordPress Memory Exhaustion Error

In this post, we have shown you not only how to fix the WordPress memory exhausted error but also how to build a resilient and high-performing website. After fixing the error, you can optimize your site by implementing a couple of best practices to prevent this in the future.

One of the most powerful preventative measures is to reduce your server’s overall workload. Every time a visitor loads a page on your site, WordPress executes PHP scripts and queries the database, all of which consume memory. Caching drastically reduces this workload by storing and serving a static HTML version of your page, bypassing the need for most PHP executions.

With RunCloud, you can enable a highly optimized server-level solution like RunCache (NGINX FastCGI cache) with a single click. This immediately lowers your server’s memory and CPU usage and makes your site significantly faster. 

This is just one example of how RunCloud transforms server management from a reactive chore into a proactive strategy. 

Sign up for RunCloud today and experience a faster, more stable WordPress site.

FAQs on WordPress Memory Exhausted Error

The post How to Fix WordPress Memory Exhausted Error Increase PHP Memory appeared first on MASSIVE News.