Category: Nginx

Introduction

Hello there, fellow server administrators, Linux enthusiasts, and all those who don’t run screaming at the mere mention of a “reverse proxy”. Today, I’d like to share the story of a migration that – much like a decent bit of sci-fi – features a few plot twists, surprises, and, with any luck, a happy ending (well, at least for now!).

For the past few years, my go-to solution for managing both web and email servers has been OpenLiteSpeed paired with CyberPanel. But, as fate (or rather, the CyberPanel developers) would have it, Ubuntu 24.04 LTS simply isn’t on their agenda. And so it’s been for more than three years now… Updates? Forget it! Support for newer Ubuntu releases? You must be joking! So here we are in June 2025, after countless requests and mounting anticipation, and CyberPanel still refuses to support the latest Ubuntu. Frankly, it doesn’t look like that’s about to change any time soon.

But every cloud has a silver lining… So I decided to take matters into my own hands. The result? A 21st-century hybrid: Ubuntu Server 24.04, ISPConfig with Nginx acting as a reverse proxy, and OpenLiteSpeed, all without the dead weight of CyberPanel. Why this particular combination? Because I like to keep control, I value performance and flexibility, and – let’s be honest – I don’t want to be held hostage by some creaky old admin panel.

This setup brings a few clear advantages:

• A fresh, supported operating system with long-term support (not some digital fossil from 2022)
• Complete control over your configuration, free from the shackles imposed by CyberPanel
• The performance of OpenLiteSpeed, combined with the straightforward management of ISPConfig
• Trouble-free handling of both websites and email (and if you’ve ever tried to wrangle mail on OLS + CyberPanel, you know exactly what digital purgatory looks like)
• Modernity, flexibility, and readiness for the future – and, as a bonus, fewer grey hairs along the way

Is this solution for everyone? Probably not – but if you’re fed up with waiting for panel updates, looking for something genuinely efficient, and like having everything under your control, stick around. In the next sections, I’ll walk you through setting up a server like this, step by step – no dark magic or needless frustration required.

Why create a separate client for each website in ISPConfig?

When setting up a server with ISPConfig, keeping things tidy and secure should be your top priority. One of the best practices is to create a separate client for every website you plan to host. This might seem a bit more effort at first, but it pays off hugely in the long run, both in terms of security and organisation.

Benefits of using a dedicated client for each website:

1. Data isolation – Each client (and therefore their sites, emails, databases) operates in its own “sandbox”. If one site is ever compromised, the others are much better protected.
2. Easier administration – Managing permissions, backups, and resource limits is much clearer and can be done per client.
3. Transparent billing – If you offer hosting as a service, it’s much easier to keep track of accounts and invoices for each client.
4. Secure email separation – Email accounts for each client are separate, so a spam incident or security breach in one does not affect the others.
5. Simpler migrations or deletions – Removing a website (along with the client) has no effect on the other sites on your server.

In this article, I’ll walk you through the process of adding a new client for a real-world example: solutionsinc.co.uk.

Limits and security in ISPConfig – why do they matter?

Once you’ve created a client in ISPConfig, one of the most important steps is setting usage limits and making sure the account is secure. ISPConfig gives you granular control over how many resources (websites, email accounts, databases, etc.) each client can use – a perfect tool for both commercial hosting and private projects.

Examples of limits you can set:

• Maximum number of web domains and subdomains
• Disk space quota (Web Quota)
• Data transfer quota (Traffic Quota)
• Number of FTP accounts, SSH users
• Access to specific technologies (PHP, Python, Ruby, SSL, Let’s Encrypt, etc.)
• Limits for emails, databases, cron jobs, and other services

Defining these limits helps you keep everything tidy, prevents accidental server overloads, and protects against abuse (such as from a misconfigured app or a DDoS attack).

Strong password – your first line of defence

A crucial part of setting up any client account is choosing a strong, complex password – ideally a random one generated by a password manager. I recommend using a password up to 64 characters long, mixing upper- and lower-case letters, numbers, and special characters. With a password manager, you won’t need to memorise it, and your account will be much safer against attacks.

Remember: Weak, repetitive or short passwords are practically an open invitation for cybercriminals!

Description of the “Web Limits” options in ISPConfig

• Webservers: The web server(s) where the client’s websites will be hosted. Usually, you select from servers previously defined in the panel.
• Max. number of web domains: The maximum number of domains the client can add. -1 means unlimited.
• Web Quota: The disk space limit for the client’s website files (in MB). -1 = unlimited.
• Traffic Quota: Monthly data transfer limit (in MB) for all the client’s sites. -1 = unlimited.
• PHP Options: Enables/disables PHP and lets you choose the handler (e.g. PHP-FPM, Disabled). Important for both security and performance.
• CGI available: Whether the client can run CGI scripts (usually disabled for security reasons).
• SSI available: Allows use of Server Side Includes.
• Perl available / Ruby available / Python available: Whether these scripting languages are available to the client’s sites.
• SuEXEC forced: Forces scripts to run with the domain user’s permissions, increasing security.
• Custom error docs available: Whether the client can set up custom error pages (e.g. 404.html).
• Wildcard subdomain available: Allows support for wildcard subdomains like *.yourdomain.com.
• SSL available: Whether the client can enable SSL on their sites (https).
• Let’s Encrypt available: Enables free SSL certificate generation from Let’s Encrypt for the client’s domains.
• Max. number of web aliasdomains: The maximum number of alias domains (extra domains pointing to the same site).
• Max. number of web subdomains: The maximum number of subdomains the client can create.
• Max. number of FTP users: Number of FTP users the client can create.
• Max. number of Shell users: Number of SSH users (usually set to 0 for security).
• SSH-Chroot Options: Whether SSH users are restricted (chrooted) to their home directory (“Jailkit”).
• Max. number of Webdav users: Limit for the number of WebDAV users.
• Backupfunction available: Whether the client can perform their own backups via the panel.
• Show web server config selection: Allows the client to select additional web server configuration options (for advanced users).

Description of the “Email Limits” options in ISPConfig

• Mailservers: The mail server where the client’s email domains and mailboxes are hosted.
• Max. number of email domains: Maximum number of email domains the client can create (-1 = unlimited).
• Max. number of mailboxes: Maximum number of mailboxes for the client (-1 = unlimited).
• Max. number of email aliases: Limit for email aliases (additional addresses that forward to mailboxes).
• Max. number of domain aliases: Number of domain aliases (extra domains mapped to the same mailboxes).
• Max. number of mailing lists: Limit for mailing lists (group distribution lists).
• Max. number of email forwarders: Maximum number of email forwarders (forwards).
• Max. number of email catchall accounts: Number of “catchall” accounts that receive all mail sent to non-existent addresses in the domain.
• Max. number of email routes: Number of email routing rules (advanced – redirecting mail to other servers based on custom rules).
• Max. number of email white / blacklist entries: Maximum number of entries on the client’s white/blacklist.
• Max. number of email filters: Limit for email filters (automatic sorting, labelling, etc.).
• Max. number of fetchmail accounts: Number of external fetchmail accounts (to collect mail from other servers).
• Mailbox quota: Mailbox size limit (in MB). -1 = unlimited.
• Max. number of spamfilter white / blacklist filters: Number of white/blacklist rules in the spam filter.
• Max. number of spamfilter users: Number of users with their own spamfilter settings.
• Max. number of spamfilter policies: Number of spamfilter policies (sets of rules).
• E-mail backup function available: Whether the client can create email backups via the panel.

Creating a database user for your website – ISPConfig

Once you’ve set up your client and defined all necessary limits, the next step is to create a dedicated database user for your website (e.g. solutionsinc.co.uk). Go to the Sites tab and find the database management section.

1. Select your client from the list (e.g. SolutionsInc).
2. Enter the database username – ISPConfig automatically suggests a prefix linked to the client (e.g. c2_). This ensures each user is unique and easy to identify.
3. Set a strong database password. Use the Generate Password button and choose a long, random password (ideally stored in your password manager). Strong passwords are essential for security, and you won’t need to remember them.
4. Repeat the password in the confirmation field.
5. Click Save to create the user.

Creating a separate database user for each website is a key security step – if the password is ever compromised, only that single site is affected. Even a serious application bug won’t give an attacker access to data from other sites on the server.

Description of the “Domain” tab options when creating a website in ISPConfig

• Server: The web server on which the domain will be hosted. Select the appropriate server from the available list.
• Client: The client to whom this domain/website will be assigned.
• IPv4-Address: The IPv4 address assigned to this domain (default is *, meaning any available IP on the server).
• IPv6-Address: IPv6 address, if used (optional).
• Domain: The domain name you wish to add (e.g. solutionsinc.co.uk).
• Harddisk Quota: The disk space limit for this particular site (in MB). -1 means unlimited.
• Traffic Quota: The monthly data transfer limit for this site (in MB). -1 means unlimited.
• CGI: Allow running CGI scripts on the site (usually disabled for security reasons).
• SSI: Enable Server Side Includes support.
• Own Error-Documents: Allows you to set up custom error pages (e.g. 404.html).
• Auto-Subdomain: Default subdomain that will be automatically added (usually www).
• SSL: Tick this if you have your own SSL certificate and want to manually upload certificates via the panel.
• Let’s Encrypt SSL: Select this if you want ISPConfig to automatically generate a free Let’s Encrypt SSL certificate for this domain (no need to have your own certificate).
• PHP: If you intend to use Nginx as a Reverse Proxy for OpenLiteSpeed, you must select PHP-FPM and exactly the same PHP version as used by OLS. Other modes (e.g. Disabled) will not work properly in this setup.
• Web server config: Additional web server configuration options (advanced, can usually be left as default).
• Active: Whether the website should be active (enabled by default – the site will work once saved).

Description of the “Redirect” tab options in ISPConfig (Reverse Proxy)

• Redirect Type: Defines the type of redirect for the domain. If you are setting up Nginx as a reverse proxy for OpenLiteSpeed, make sure to select proxy here. This ensures HTTP/S traffic is properly forwarded to the backend (OLS).
• Redirect Path: The target address (URL/backend) where the traffic should be proxied. For reverse proxy, enter the backend address here (e.g. http://127.0.0.1:8088/ – do not use port 8080, as this port is used by ISPConfig!).
• SEO Redirect: Optional SEO redirects (e.g. 301, 302, non-www→www). Usually set to “No redirect” unless you have specific SEO requirements.
• Rewrite Rules: Field for custom rewrite rules, compatible with the nginx_http_rewrite_module. Here you can add additional HTTP instructions, e.g. break, if, return, rewrite, set (full list on the nginx documentation site).
• Rewrite HTTP to HTTPS: If checked, automatically redirects all HTTP traffic to HTTPS. Recommended for sites requiring SSL.

Note: For reverse proxy setups, it is essential to set Redirect Type to proxy and specify the correct backend address in Redirect Path.

SSL tab in ISPConfig – what should you set here?

• If you have ticked Let’s Encrypt SSL in the Domain tab, you don’t need to fill in anything here. The certificate will be generated automatically and these fields can remain empty.
• If you are using your own SSL certificates, paste the relevant content into the fields below:
  • SSL Key: The private key
  • SSL Request: The Certificate Signing Request (CSR) – optional, if you use it
  • SSL Certificate: The actual SSL certificate (public certificate)
  • SSL Bundle: Any intermediate certificates/CA Bundle (if required by your certificate provider)
• SSL Domain: The domain for which the certificate is generated/installed (autofilled)
• SSL Action: By default, “Save certificate” – saves the details you enter

Tip: If you switch certificate type (for example, from a custom certificate to Let’s Encrypt or vice versa), remember to untick any unnecessary options in the Domain tab and save your changes.

Statistics tab in ISPConfig – your own web analytics

If you want an independent statistics system for your website (other than what’s provided by WordPress or Google Analytics), this is the place. Here you can choose which program will generate and display detailed traffic statistics for your site. Here’s a brief overview of the available options:

• AWStats: The most popular tool for detailed website statistics. It analyses server logs and presents readable charts, traffic summaries, referrers, search phrases, and more. Features a web interface and multi-language support.
• GoAccess: A modern, real-time log analyser with its own web interface. Very fast, provides clear summaries of key metrics (unique visitors, most popular pages, error codes, etc.). Slightly more technical than AWStats.
• Webalizer: An older but very lightweight and fast log analyser. Shows basic traffic stats, hourly/daily graphs, top visited pages, but with less detail than AWStats.
• None: No statistics will be collected. Useful if you use only external analytics solutions or want to save system resources.

Tip: Make sure to set a password for the statistics panel if you want to keep access restricted!

Backup tab – Your safety net (and peace of mind)

This tab lets you set up automatic backups of your website and database, or make a manual backup whenever you’re feeling sensible (or have a sudden flash of paranoia – both are valid).

Available options:

• Backup interval: How often to run backups (e.g. daily, weekly, monthly, or never – but I definitely don’t recommend that last one!).
• Number of backup copies: How many recent backups to keep on the server.
• Excluded Directories: Folders to skip during backup (like cache or temp data).
• Compression options: Compress your backups so they don’t fill up your server – highly recommended!
• Encryption options: Encrypt your backups, so even if someone gets their hands on them, your data stays safe.

Manual backup: Two handy buttons – make a database backup or a web files backup in a single click.

Anecdote: There are two kinds of people: those who make backups, and those who will start making them… right after their first real disaster. Trust me, you want to be in the first group!

Options tab – crucial for Reverse Proxy (Nginx → OLS)

If you use Nginx as a Reverse Proxy for OpenLiteSpeed (or another backend), you must configure the correct headers in the Proxy Directives field. Paste the following lines there:

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

Why is this important?

• proxy_set_header Host $host;
  Passes the original host name (domain) that the visitor used. This ensures the backend (OLS) knows which virtual host the request is for and serves the correct website.
• proxy_set_header X-Real-IP $remote_addr;
  Forwards the real client IP address (not the proxy’s address). This is crucial for logging, statistics, and security features – you’ll always see the true visitor’s IP.
• proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  Adds the client’s original IP address to the X-Forwarded-For header. Especially useful if your traffic passes through multiple proxies, so you can trace the full request path.
• proxy_set_header X-Forwarded-Proto $scheme;
  Tells the backend whether the original request used HTTPS or HTTP. Essential for your apps to generate correct return links (e.g., https:// instead of http://).

Summary:
Without these headers, your backend (OLS) won’t know who’s really visiting your site, which domain they’re using, or whether they’re using HTTPS. The consequences? Incorrect logs, broken redirects, SSL issues, and even security holes.

Final step: configuring OpenLiteSpeed for Reverse Proxy

Once all ISPConfig settings are in place, head over to the OpenLiteSpeed admin panel at http://SERVER_IP:7080.

What to do:

1. Go to the Listeners section.
2. Delete all listeners except for the Listener Default on port 8088 (this is where OLS will receive requests from the Nginx reverse proxy).
3. Click the magnifying glass icon for your listener and open the Virtual Host Mappings tab.
4. Add a mapping for your site, e.g. solutionsinc.co.uk (or whichever domain you configured in ISPConfig).

Why this way?

• SSL management (certificates, renewals, redirects, etc.) is now fully handled by Nginx and ISPConfig – no need to set up SSL in OLS.
• Other listener settings can be left as-is – from now on, Nginx will handle all the “heavy lifting”.

Summary:
From now on, Nginx will handle all incoming traffic (including HTTPS) and forward clean requests to OLS over the local port (8088). This is a perfect blend of performance, flexibility, and security.

Virtual Hosts > Basic in OpenLiteSpeed – how to fill in the fields correctly?

1. Virtual Host Name: Enter the virtual host’s name, e.g. solutionsinc.co.uk .
2. Virtual Host Root: Use exactly the path from the Document Root field in ISPConfig (e.g. /var/www/clients/client1/web1/), making sure to include the trailing slash /. This ensures OLS serves files from the right location.
3. Config File: Enter bashKopiujEdytuj$SERVER_ROOT/conf/vhosts/$VH_NAME/vhost.conf When you try to save, OLS will warn you that this file does not exist – click the link below the field to create it automatically. You’ll then be able to save your settings.
4. suEXEC User and suEXEC Group:
   Select the exact user and group that ISPConfig created for your domain. You can check this in ISPConfig under Sites > Website > Options.
   This is crucial – it ensures OLS runs PHP scripts with the correct permissions, improving security and isolating your site from other users’ files.
5. External App Set UID Mode: Choose DocRoot UID. This ensures external apps (like PHP) run as the user assigned to your site’s directory.
6. In the Security section, you’ll find options that are essential for the secure and correct functioning of your virtual host. Set each of them to Yes:
   • Follow Symbolic Link:
     Allows OLS to follow symbolic links in your site directory. This is required by some applications, frameworks, or during software updates.
   • Enable Scripts/ExtApps:
     Lets you run scripts (like PHP) and external applications. Without this, your website won’t be able to process PHP or use any dynamic features.
   • Restrained:
     Enables “restrained” mode – increases security by limiting which system commands the virtual host can execute.
   • Remember:
   • All these options must be set to Yes for your site to work correctly and securely with ISPConfig and a reverse proxy setup.

General tab – OpenLiteSpeed Virtual Host

The most important options:

• Document Root:
  The directory where your website’s files are located. Paste the path from ISPConfig (Sites → Website → Document Root), then add your site’s directory, usually /web/, at the end, e.g. /var/www/clients/client1/web1/web/. Always check this path in ISPConfig, as it may differ!

Other options:

• Domain Name:
  (Optional) Main domain name for this vhost.
• Domain Aliases:
  Alternative domains that should also point to this vhost (e.g. www and non-www versions).
• Administrator Email:
  Email address of the site admin (for error notifications).
• Enable GZIP Compression:
  Enables GZIP compression on the server – speeds up page loading.
• Enable Brotli Compression:
  Alternative, more efficient compression method than GZIP.
• Enable GeoLocation Lookup:
  Lets the server detect users’ country (e.g. for stats).
• cgroups:
  Optional resource limits for this vhost (CPU/RAM quotas).

Index Files section:

• Use Server Index Files:
  Should be set to “No” so OLS uses the index files defined below, not global server defaults.
• Index Files:
  List of filenames that should be treated as the site’s entry point (e.g. index.php, index.html). The first found file will be used.
• Auto Index:
  Allows automatic directory index if no index file exists (recommended to leave off for security reasons).
• Auto Index URI:
  Lets you define a URL to show the auto-generated index.

Customized Error Pages:

• Specify custom error pages here (e.g. for 404 or 500 errors).

Expires Settings:

• Enable Expires, Expires Default, Expires By Type:
  Control how browsers cache static files (how long files should be kept). Usually left as default; you can manage cache with .htaccess or your app settings.

File Upload:

• Temporary File Path, Temporary File Permission, Pass Upload Data by File Path:
  Advanced file upload settings – where temp files go, their permissions, and whether upload data is passed by path (usually leave as default).

php.ini Override:

• Lets you specify custom PHP settings just for this vhost – if you don’t need to tweak (like upload_max_filesize), leave it blank.

Log tab – separate logs for every site

Why use separate logs?

• Isolation: Per-site logs make management, troubleshooting, and auditing much easier – no need to search a massive, shared file.
• Security: If you have multiple clients or projects, separate logs help maintain data privacy and organisation.
• Easier analysis: You can quickly spot attacks, errors, or unusual requests for each website.

Virtual Host Log (error log)

• Use Server’s Log:
  Set to “No” to keep this site’s error logs separate from global server logs. Recommended – makes it much easier to spot issues for a specific site.
• File Name:
  Path to this site’s error log (e.g. /var/www/clients/client1/solutionsinc.co.uk/log/error.log). Keeping logs in the domain directory makes backup and access easier.
• Log Level:
  How detailed the logs should be (DEBUG, INFO, NOTICE, WARN, ERROR, CRIT).
  DEBUG is the most detailed – great for troubleshooting, but for production use WARN or ERROR.
• Rolling Size (bytes):
  Max log file size before a new one is created (e.g. 10M). Prevents disk space exhaustion.
• Keep Days:
  How many days to keep old logs. Useful for auditing and investigating past incidents.
• Compress Archive:
  Whether to archive and compress old logs. Recommended if you have lots of logs – saves disk space.

Access Log

• Log Control:
  Choose “Own Log File” so each vhost has its own access log. Makes it much easier to analyse traffic for individual sites.
• File Name:
  Path to the access log file (e.g. /var/www/clients/client1/solutionsinc.co.uk/log/access_log).
• Piped Logger:
  Advanced – logs can be processed “live” by external programs. Leave empty unless needed.
• Log Format:
  Log entry format. The default works for most needs, but you can customise it for special analysis.
• Log Headers:
  Tick “Referrer”, “UserAgent”, “Host” – this ensures logs have key info about visitors, sources, and devices.
• Rolling Size (bytes):
  Max log file size before rolling over (e.g. 50M).
• Keep Days:
  How long to keep access logs (e.g. 365 – a full year’s history).
• Compress Archive:
  Set to “Yes” so old logs are compressed automatically.
• Bytes log:
  Optional: a file for tracking bytes transferred (mainly for advanced analysis).

Recommended settings:

• For production, set Log Level to WARN or ERROR; use DEBUG only during setup and testing.
• Always compress archived logs.
• Keep logs for at least 30 days – 90 or more is ideal if you have the space.
• For access logs: always use a separate file per domain, and always include Referrer, UserAgent, and Host.

Security tab – explanation of all options

Note:
You do NOT need to configure any of these settings for your site to work with Nginx as a Reverse Proxy!
Unless you are an advanced user, it is best to get your site working first, then come back here to experiment with security settings.

Section: LS reCAPTCHA

• Enable reCAPTCHA, Site Key, Secret Key, reCAPTCHA Type, Max Tries, Concurrent Request Limit
  Allows you to enable reCAPTCHA mechanisms (protection against bots and brute-force attacks at the server level). You need to provide Google keys and set attempt limits.
  Practice: Use only if you know exactly what you are doing – misconfiguration may block access to your website!

Section: Containers

• Bubblewrap Container
  Runs the vhost in an isolated Bubblewrap container (extra security, as apps are “cut off” from the rest of the system).
  Advanced! Not recommended for beginners.
• Namespace Container, Additional Namespace Template File
  Lets you isolate the vhost in its own Linux namespace (further boosts security, but requires knowledge of Linux containers).

Section: Access Control

• Allowed List
  List of IP addresses that are allowed access to the site.
• Denied List
  List of IP addresses that are denied access. Warning: If set incorrectly, you might accidentally lock yourself out of your own website!

Section: Realm List

• Here you can set up “realms” – server-level authentication zones (like password-protecting a directory).

Practical summary

• For your site to work with Nginx as Reverse Proxy, you do NOT need to set anything here.
• These features are mainly for advanced admins – for most users, it’s best to leave them at default until your site is working smoothly.
• Recommendation: Get your site up and running first, check everything is OK, then (optionally) return here to tweak security settings.

External App tab – options and recommendations

This tab is responsible for connecting your web server to the PHP interpreter, so your PHP applications work correctly.

Key fields:

• Name:
  Name of the external application, e.g. solutionsinc.co.uk. Use your domain name for clarity.
• Address:
  IMPORTANT!
  The socket for communicating with PHP, e.g. UDS:///tmp/lshttpd/solutionsinc.co.uk.sock
  UDS (Unix Domain Socket) must be uppercase! This enables faster and more secure communication than TCP.
• Notes:
  Any optional notes/description.
• Max Connections:
  Max number of simultaneous PHP connections. 50 is good for most sites. Increase for heavy-traffic sites.
• Environment:
  Additional environment variables. Example: LSAPI_CHILDREN=50 – sets the number of PHP child processes.
• Initial Request Timeout (secs):
  How long to wait for the first PHP response (e.g. 600 seconds). Increase for slower servers or long-running scripts.
• Retry Timeout (secs):
  How long the server waits and retries if connecting to PHP fails.
• Persistent Connection:
  “Yes” is best – keeps PHP connections alive for faster handling of multiple requests.
• Connection Keep-Alive Timeout:
  How long (in seconds) to keep PHP connections open after serving a request (default 1).
• Response Buffering:
  “No” means responses are sent to the client immediately – recommended for dynamic websites.
• Start By Server:
  “Yes (Through CGI Daemon)” – the server starts PHP automatically; this is safer and more convenient.
• Command:
  CRUCIAL!
  Path to the PHP interpreter, e.g. /usr/local/lsws/lsphp83/bin/lsphp
  Make sure this file exists and matches your desired PHP version. How to check:
  In your server console, type: bashKopiujEdytujls -l /usr/local/lsws/lsphp83/bin/lsphp If the file exists, the path is correct. If not, check if PHP 8.3 is installed via LiteSpeed (use the LiteSpeed manager or the lsphp command).
• Back Log:
  Max number of pending PHP requests (100 is recommended).
• Instances:
  Number of app instances (i.e., separate PHP processes). Normally 1 unless you have special needs.
• Run As User / Run As Group:
  Must match the user and group defined in ISPConfig for this site (e.g. web1/client1). This ensures each vhost runs with only its own permissions – much better security.
• umask:
  Permission mask for new files – leave blank unless you have a reason.
• Run On Start Up, Max Idle Time, Priority:
  Advanced – normally leave as default.
• Memory Soft Limit / Hard Limit:
  Soft/hard RAM limits for the PHP process (in bytes).
  Recommended: 2047M (2GB). Adjust for your server and application needs.
• Process Soft Limit / Hard Limit:
  Limit the number of processes (soft/hard).
  Soft = warning, hard = cap. Example: Soft 400, Hard 500.

Script Handler tab – what does it do?

This section determines which application handles specific script file types (e.g. PHP) at the Virtual Host level. Without the right handler, PHP simply won’t work!

Key options:

• Suffixes
  Enter the file extension(s) you want this handler to process.
  Typically, just enter: nginxKopiujEdytujphp This ensures all files ending with .php are processed by PHP.

Suffix – what is it and how should you set it?

Suffix specifies which script file extensions will be handled by this script handler. Each suffix must be unique within your configuration.

Syntax:

• Comma-delimited list without the period (“.” character is prohibited).
• Example: KopiujEdytujphp,php83

Important notes (based on OLS documentation):

• The server will automatically add a special MIME type (application/x-httpd-[suffix]) for the first suffix in the list.
  • For example, for php83, MIME type application/x-httpd-php83 will be added.
• If you wish to use additional suffixes (like php53,php74), you must manually set up the corresponding MIME types in the “MIME Settings” after the first one.
• Although this field lists suffixes, script handlers actually use MIME types, not suffixes, to decide which scripts to process.
• Only specify suffixes you really need – avoid listing unused extensions, as this could introduce security or configuration risks.

Example of correct configuration:

To handle only .php files:

php

To also handle .php83 files:

php,php83

Remember: for extra suffixes, add the appropriate MIME types in your server’s settings!

• Handler Type
  The type of script handler.
  LiteSpeed SAPI is the fastest and most direct way to run PHP on OpenLiteSpeed – it links directly to your PHP process as configured in the External App tab.
• Handler Name
  Select the application you defined in the External App section.
  If you have several virtual hosts, you can have different PHP versions/configurations for each.
  Tip:
  It should say [VHost Level]: solutionsinc.co.uk – meaning the handler set up specifically for this website.

Why is this important?

• Without a proper handler for PHP, your server won’t know how to execute .php files (it might try to send them as plain text instead of running the code!).
• Using LiteSpeed SAPI ensures the best performance, security, and PHP compatibility.
• If you host multiple sites, each with different PHP needs (e.g. one site needs PHP 8.3, another needs PHP 8.1), you can assign a different interpreter to each virtual host.

Rewrite tab – what does it do?

The Rewrite tab allows you to manage URL rewriting rules (“mod_rewrite”), which are essential for:

• Clean/friendly URLs (for WordPress, Prestashop, Laravel, etc.).
• Forced redirects (e.g. http→https, non-www→www).
• Custom rewrite logic (folder masking, domain aliases, etc.).

Field descriptions

Rewrite Control

• Enable Rewrite
  Enables the rewrite engine (mod_rewrite) for this Virtual Host.
  Important: Without this, no .htaccess or custom rewrite rules will work!
• Auto Load from .htaccess
  Automatically loads rewrite rules from .htaccess files found in your site’s directories.
  Important:
  • For WordPress and most CMSes, this must be “Yes”.
  • If you want maximum performance, you can place rewrite rules directly in “Rewrite Rules” and turn this off.
• Log Level
  Specifies the detail level of the rewrite engine’s debug output.
  • Value range: 0–9
    • 0 – disables rewrite logging.
    • 9 – produces the most detailed debug log.
  • The higher the value, the more information you get about how rewrite rules are processed.
  • For this setting to take effect, the server and/or virtual host error log must be set to at least INFO.
  • Especially useful for testing or debugging rewrite rules.
  • Syntax: Integer between 0 and 9.

Rewrite Map
Lets you define rewrite maps (advanced usage – e.g. dynamic redirects using patterns or files).

• Most users don’t need this.

Rewrite Rules
Here you can manually enter mod_rewrite rules (Apache style).

Example:

RewriteEngine On

RewriteCond %{HTTPS} !=on

RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Rules here override those from .htaccess.

Why is this important?

• Without rewrite, many apps will not work properly (no pretty URLs, 404 errors).
• Automatic .htaccess loading allows you to use ready-made .htaccess files from popular CMSes.
• Manual rules are useful for maximum control or performance.

Context Tab – Field Descriptions

1. URI

• Description: The path (URI) of the directory or subdirectory to which you want to apply this context.
• Crucial! This must match exactly the folder where your website is located (e.g. /web/ for /var/www/clients/client1/web1/web/).
• Note: If the URI ends with a /, all subdirectories beneath it are included in this context. If your site is in the root, simply use /.

2. LSAPI App

• Description: Select the LiteSpeed SAPI application (e.g. PHP) that should handle this context. The dropdown list contains applications defined under External App.
• Why it matters: This links PHP (or another language) processing to your website. Without it, PHP will not work in this directory!

3. Notes

• Description: An informational field where you can add your own notes.
• Tip: Useful for larger installations or when testing, but not required for basic setups.

4. Header Operations

• Description: Allows you to add, append, or unset HTTP response headers (e.g. for cache control or security).
• Syntax: Similar to Apache’s mod_headers.
• Example: pgsqlKopiujEdytujset Cache-control no-cache append Cache-control no-store
• Tip: Handy if you want to control caching or security headers for a particular directory.

5. Realm / Authentication Name / Require (Authorised Users/Groups) / Access Allowed / Access Denied / Authorizer

• Description: Options for restricting access to this directory (you can set up basic authentication, or allow only certain users or groups).
• Tip: Leave these blank unless you want to protect a folder (such as an admin area or testing section) with a password or by user group.

6. Add Default Charset

• Description: Controls whether a default character set is added to HTTP responses.
• Default: Off
• Set if: You need to enforce a particular character encoding (for example, UTF-8) for your website.

7. Customized Default Charset

• Description: Lets you specify your own default character set (e.g. UTF-8, ISO-8859-2).
• Set if: Your site requires a specific encoding.

8. Enable GeoLocation Lookup

• Description: Enables geographical IP lookup for users visiting this context.
• Tip: Leave off unless you specifically need to personalise content or restrict access by country.

Why is the Context tab important?

• The Context tab allows you to precisely control how the server handles specific directories or subdirectories – for example, using a different PHP version for /admin/, securing a login area, or setting security headers for a particular folder.
• The URI field is essential: if this path is incorrect, your settings will not take effect.
• This flexibility goes far beyond what typical shared hosting offers, letting you tailor configuration to your needs.

Summary

After completing all of the above steps – from ISPConfig setup, to configuring Nginx as a reverse proxy, and fine-tuning the options in OpenLiteSpeed – your WordPress site or application should be up and running, provided you’ve set your DNS records correctly (for example, in CloudFlare). Without those, even the most beautifully configured server will be as empty as the office on a Friday at 5pm!

If everything works – congratulations! You can now put the kettle on and enjoy the feeling of running a truly robust, modern server setup. And if things aren’t quite right… double-check your DNS, your logs, and maybe question the wisdom of midnight sysadmin adventures. Good luck, and may your uptime be as solid as your sense of humour!