Will my site be marked unsafe in Chrome 56+?

Lately there’s been a lot of speculation about Googles up-coming changes to how sites without an SSL are going to be treated. As January draws towards a close we have seen an increase in customers with concerns of how this will affect their site. Both in terms of people being able to see it and how it might affect their search ranking.

This article aims to clear up some of the confusion and to demystify the changes. If you are unfamiliar with how SSL/TLS or HTTPS works please take a look at our article on the subject.

If you aren’t interested in how these changes came about feel free to skip down to: How These Changes Affect Your Site
Continue reading “Will my site be marked unsafe in Chrome 56+?”

Cloud Sites – Powered by Liquid Web

Welcome Cloud Sites customers. The following is to help answer questions you may have as you prepare to utilize your Cloud Sites account with Liquid Web. For more information beyond the questions below, feel free to reference this note from Jim Geiger, CEO of Liquid Web.

General Questions

  • Who does this impact?

    Rackspace Cloud Sites customers will have only the Cloud Sites product transitioned to Liquid Web. All other Rackspace services will continue to be managed, operated and invoiced via Rackspace. Only the Cloud Sites product is transitioning.

  • What happened?

    Rackspace has shifted focus away from Platform as a Service (PaaS) Web Hosting and has sold the Cloud Sites product, customer base, support team and all infrastructure to Liquid Web, who is a leader in this market space.

  • When did this happen?

    Rackspace sold the Cloud Sites product in Aug 2016. During the months since the sale, Rackspace and Liquid Web have been working to smoothly extricate the Cloud Sites product and customer base from Rackspace. As Cloud Sites was a foundation product in Rackspace, the interdependencies in the management/billing/support infrastructures were extensive. Ensuring a smooth transition for our customers is the goal of both Rackspace and Liquid Web.

  • Why did this happen?

    Rackspace has refocused its strategy on large, complex infrastructure deployments and consultative services. As Rackspace’s strategy shifted, Liquid Web stepped in as an ideal choice to acquire Cloud Sites. Why? Because we are dedicated to partnering with professional website designers, developers and digital agencies and the businesses they serve.

  • Will my price increase?

    No. Your pricing will not change. In fact, we intend to enhance and bolster your services at your current pricing level.

  • Will my websites stop working?

    Absolutely not. We are dedicated to making this transition smooth and are committed to ensuring uninterrupted service for your websites and customers. The activation of new Liquid Web accounts only impacts the management of your account and websites. It does not impact the operations of the websites.

  • What will be changing?

    As you join our Liquid Web family, three important steps will take place:

    1. In the near future, you will receive an account activation ticket. This account is your front door to Liquid Web and is used to manage your products and account information in your new home.
    2. Next month we will be introducing the New Cloud Sites Control Panel and adding your Cloud Sites product to the Liquid Web account for you .
    3. Finally, after your account has been transferred, you will start receiving your Cloud Sites invoices from Liquid Web.

Your Liquid Web Account(s)

  • What changes will I need to make to manage my account?

    Once you receive your new Liquid Web account and activation instructions, you will need to log into your new account, update your password and establish a new secret question/passphrase. You will want to make sure your contact information and credit card information is up to date to ensure a smooth transition and no interruption in your website operations.

  • How do I pay my bill?

    Your credit card will continue to be invoiced for the Cloud Sites product. Your statement will reflect Liquid Web as the source for your Cloud Sites charges. The Help Center article “Understanding the Billing Tab in Your Account” explains the billing options and tab in the control panel. Cloud Sites will be one of the services on your new account.

  • Can I use a different payment method?

    Liquid Web allows for a number of different payment methods, including credit card and paypal.

  • Do I have to keep the same username?

    No. Once you have responded to the activation ticket and are logged into your Liquid Web account, you can change your username. The Help Center article “Editing User Authorizations” provides a quick walk through. Or you can go directly to Account > Users > Edit in your new control panel. A best practice would be to make this username and password unique from your old Rackspace account.

  • Do I have to keep the same Account Name?

    No. You can change all of your profile information via the new control panel, including the Points of Contact and the Organization Name. The Help Center article “Updating Your Profile” provides an overview of this easy process.


  • Is my support team changing?

    No, Liquid Web has retained 100% of the Cloud Sites team including all of the support team.

  • Whom do I contact for support?

    Your Cloud Sites support team and contact information remains the same. You can call 1-855-348-9060, or reach out via ticket or chat.

  • Does Liquid Web have a Status Page?

    Yes. You can see the latest information on maintenance schedules and any service issues at our dedicated Cloud Sites Status Page.

New Cloud Sites Control Panel

  • Will there be a new Cloud Sites Control Panel?

    Yes. We are excited to announce the launch of the new Cloud Sites Control Panel. After account activation and close to your next Cloud Sites invoice, your Cloud Sites service will be transitioned into your Liquid Web account. At that time, you will gain access to and see numerous user-friendly enhancements in the new Cloud Sites Control Panel. We look forward to bringing you future enhancements as we invest in the Cloud Sites product.

  • Will the Cloud Sites Control Panel look the same?

    No. We have worked hard to integrate the Cloud Sites product with the many services offered by Liquid Web, however, the processes for some services will be handled differently. We are excited that the new features and streamlined Cloud Sites interface will improve workflow and make managing your sites more intuitive.

  • Will I still have access to the old Cloud Sites Control Panel?

    Once you are transitioned to the new Cloud Sites Control Panel, your access to the Rackspace Cloud Sites Control Panel will terminate. It is not possible to have multiple control panels managing your Cloud Sites resources.
    If you need to access other Rackspace services, your Rackspace username and password will continue to work at http://mycloud.rackspace.com .

  • How do I access the new control panel?

    We need to polish a few of the features, so the new control panel is not ready for your use at this time. But, don’t worry we will be adding that soon. Once the Cloud Sites Service has been added to your Liquid Web account, you can access the new control panel via a direct link on the Liquid Web control panel. Or you can use your Liquid Web primary account to access the new control panel directly at https://cloudsites.liquidweb.com. Currently, only the account owner will have direct access via the URL. Adding more users and roles is one of the many features we are working to add for you.

  • Will the new control panel have a new URL?

    Yes. Once your Cloud Sites service is added to your Liquid Web account, the account owner will be able to log directly into the new control panel at https://cloudsites.liquidweb.com. Please remember that only the account owner will be able to log in directly, at this time.

  • Will this impact my existing FTP accounts?

    No, all of your present FTP accounts will function as before and will not require any changes. You and your users will be able to access your website resources.

  • Will there be a White Label user interface?

    Yes, your customers will use their existing username and password after the control panel transition to reach a new white label interface at https://manage.websitesettings.com.

  • How can I learn about the new Control Panel?

    The Help Center has a number of articles for Cloud Sites. Presently, those articles focus on the primary account features and give you a head start on how the control panel will function, but we are still polishing some features for your customers (Rackspace sub-accounts). In mid-February, we will be launching the new control panel with these additional features for you.

Domain Management

  • Will I still be able to use Click & Name as my Domain Registrar?

    The Click & Name domain registrar will maintain your already registered domains. However, Click & Name will be phased out over time and renewals will not be available after the Cloud Sites Control Panel transition. The new Cloud Sites Control Panel will allow you to manage your domain point of contact information and generate transfer documentation. If you need assistance with these actions our support team will be glad to assist.

  • Who can I use to register my domain?

    Liquid Web is partnered with Enom and has an integrated Domain Registration Service in your new Liquid Web account. When you are ready to register your domain, the control panel allows for quick and easy setup. In addition, the much-requested ability to automatically renew your domain is a simple one click addition to your registration.

  • Can I transfer my domain out of Click & Name to Enom?

    Absolutely. We have simplified the process so that it only takes a few steps, starting with a ticket request. Because the process is regulated by international standards (ICANN), this process can take a few days and does required your validation of the request. Our support team will guide you through the process and answer any questions you may have.

  • Do I have to change my websites’ DNS servers?

    In order to ensure uninterrupted website service your DNS records will continue to exist in the Rackspace DNS servers. You can view those DNS records via http://mycloud.rackspace.com. For your convenience we have copied those DNS zones into the Liquid Web DNS servers as well. Once you update your domain registrar with the Liquid Web DNS servers, you can consolidate your DNS management within the Liquid Web control panel. If you need assistance with changes with domains registered through “Click & Name” our support team will be glad to assist.

  • Can I use Liquid Web to manage my DNS servers?

    Yes, we have copied your DNS zones into the Liquid Web DNS servers. You can view those DNS zone records in the Liquid Web control panel under Domains > DNS. The Help Center article “Where Is My DNS Hosted?” provides information on how to determine who your domain registrar is using for your DNS service. Best practice is to ensure those DNS zone records in your Liquid Web account are accurate before you update your domain registrar.


  • Will my sites be migrated to a new location? If so, what are you doing to ensure a smooth transition?

    Eventually your data will be migrated to a Liquid Web data center, featuring industry leading hardware and premium security. At the appropriate time, you will receive advanced notification for the schedule of this transition as well as any role we may need you to play.
    We have assigned a dedicated team to work on your upgrade.

  • Will my IP addresses change?

    There are no initial IP address changes, at this time. In the future, as we integrate more of the Cloud Sites Infrastructure into Liquid Web Data Centers, this may change. For the majority of customers, there will be no IP Address change. If you are one of the few customers whose IP Address will require a change, we will notify you and guide you through the process.


  • Will my existing Cloud Sites services change?

    No. You will continue to enjoy the same Cloud Sites services and they will be integrated with present Liquid Web services, as well.

  • How do I order new or additional services?

    Once you receive your new account, your Cloud Sites subscription will automatically transfer to Liquid Web for billing. If you have other Rackspace services, those will remain with Rackspace and will continue to be invoiced by Rackspace. You will be able to add additional Liquid Web services after your account has been activated within our Liquid Web systems.

  • Who do I contact if I want to discuss Liquid Web Services?

    We have a solutions team eager to assist you. They can be reached at 800.580.4985 (1-517-322-0434). Asking for a Hosting Advisor will get you directly to an engineer who will use their extensive hosting expertise to design and deploy a custom solution for your specific objectives.

What Is a web.config File?

If your server uses IIS, you can use web.config files to control your website’s configuration without editing your server configuration files. You can even apply different settings to different directories within your website.

You can easily create a web.config file by creating a plaintext file and uploading it to your server. If you have multiple web.config files, remember that files higher up in the filepath always take precedence. If you want to make a configuration change to your whole server, we recommend editing server-level IIS settings instead.

Before making any changes to configuration files, we strongly recommend you take a backup of the file.

Some common uses for web.config files include:

  • redirecting URLs to be more easily readable (e.g., mysite.com/product/shirt instead of mysite.com/prodid=1234)
  • loading custom error pages (e.g., 404 pages)
  • forcing your site to use https instead of http.
  • password protecting certain directories
  • preventing hot-linking

If you have a server that uses Plesk, we recommend using the Plesk control panel to change these types of configurations instead of web.config files. You can also use the File Manager in Plesk to edit the web.config file.

How KernelCare Protects Your Server

One of the most important things you can do to ensure the security and stability of your Linux server is to keep the kernel updated. Some Kernel updates patch security vulnerabilities and other issues. Kernel patches are released as issues are discovered.

Unless you are regularly checking for kernel updates, or your notified of a security issue, you may not be aware when a kernel update is available. Additionally, since updating the kernel traditionally requires a reboot, the prospect of associated downtime often prevents the updates from being applied as quickly as they should be.

KernelCare changes all that.

Automatic Updates; No Reboot Necessary

KernelCare is a CloudLinux product that automatically updates the Linux kernel to address security and stability issues without the need for a server reboot, even during its initial install. You can read more on KernelCare in our article: What Is KernelCare?

Liquid Web provides KernelCare on all new managed Storm® and Dedicated servers running a supported operating system (CentOS 5, 6, and 7, which also may report as “Derived From Red Hat Enterprise Linux”; or CloudLinux 5 and 6). Moreover, as part of Liquid Web’s proactive response to security concerns, KernelCare has been applied to nearly all existing Fully Managed servers running a supported operating system.

What Does It Mean For You?

KernelCare runs transparently on your server. There are no settings you need to configure nor commands that need to be run once installed. KernelCare will regularly check for kernel updates and automatically apply them as they become available with no impact on your server or services.

With KernelCare you never have to worry if your server’s kernel is protected against a particular vulnerability. You know it is. You never have to worry about downtime caused by rebooting to apply a kernel patch; cause there is none. And you never have to worry about how long you’ll have to wait for a new patch to be applied to your server. KernelCare offers the most efficient protection by automatically updating the kernel as soon as a patch is available, with no need for a reboot.


Liquid Web’s Heroic Support is always available to assist customers with this or any other issue. If you need our assistance please contact us:
Toll Free 1.800.580.4985
International 517.322.0434

What Is KernelCare?

Tux the Penguin with Hotpatching (KernelCare)The concept of ‘Kernel hotpatching’, sometimes called live patching, was introduced to the Linux community around 2008. Soon after groups began developing differing implementations of the concept. KernelCare, one of the more popular implementations, was originally released in March 2014 by Cloud Linux, Inc.

So, what does hot patching do? (Or: Why do I want KernelCare?)

The basic concept of Linux kernel hot patching is pretty much the same not matter what it’s called. The goal is to only update the changes rather than the whole Kernel – which normally requires a reboot. It’s much harder than it sounds though since kernel updates come as complete packages and the system is running.

Imagine trying to do an oil change on your car while driving at highway speeds; that’s kernel hot patching in a nutshell.

With a KernelCare enabled kernel updates can be processed and then applied selectively to a running server. This can mean not needing to reboot for much longer than you would normally require to stay secure.

How do I check if I have KernelCare and is it working? (Or: Checking KernelCare version)

The best way to check if your server is running with KernelCare is to look for its main CLI tool. You can do this with the following linux command:

which kcarectl

If the CLI tool is found on the server you will see output like the following, or something very similar.

# which kcarectl

If the CLI tool is not installed you will see the following:

# which kcarectl
When using the Linux `which` command you will get no results if the executable is not found. In this case that means KernelCare is likely not active or installed on the server.

Assuming the test above was successful, you’ll now want to check the status of KernelCare. This will help you determine if KernelCare is active and what the effective version is. You can do this with the following command:

/usr/bin/kcarectl --info

The results will look similar to the following:

[root@host ~]# /usr/bin/kcarectl –info
kpatch-state: patch is applied
kpatch-for: Linux version 3.10.0-327.36.3.el7.x86_64 (builder@kbuilder.dev.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-4) (GCC) ) #1 SMP Mon Oct 24 16:09:20 UTC 2016
kpatch-build-time: Mon Nov 7 08:20:19 2016
kpatch-description: 2;3.10.0-327.36.3.el7.x86_64

As you can see the output provides various details about the KernelCare status. Looking at the kpatch-state we can see that hot patching is working and enabled.

Understanding the Default WordPress .htaccess

When maintaining a WordPress site you may find yourself attempting things that normally would work and find that they have unexpected results. This is usually due to how WordPress’ default .htaccess rules manipulate the configurations and provide ‘pretty permalinks’.

This article is directly applicable to WordPress on an Apache based server. For WordPress Multi-site or other web servers (Nginx, IIS, etc) please review the official WordPress documentation as rules and configurations may differ.

The Default Rules

The default WordPress .htaccess rules are responsible for how WordPress is able to support ‘pretty permalinks’. Without these rules in place, WordPress permalinks would not resolve correctly. This feature allows your URLs to look much cleaner and more readable without over complicating or cluttering your website’s files structure.

The default rules look as follows:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

To break down what these rules are defining we’ll start at the top and work our way down.
  • First, you see a comment as indicated by the hashtag; this symbol `#` is used to denote a comment in .htaccess files.
  • Next you see an opening brace for Apache’s internal “IfModule” function; this specifies that the contained rules should only be used with the “mod_rewrite” module for Apache.
  • The Rewrite module is enabled.
  • The RewriteBase is declared; this defines the ‘root’ folder that should be applied to rewrite rules.
  • The next line is the first rewrite rule, this rule defines that if an “index.php” file is specifically called then no rewrite is needed.
  • The next two lines are both defining rewrite conditions; these conditions are specifying that if no file or folder can be found at the given URL the next rule should be applied.
  • Finally, the last rewrite rule before the close brace is for the “IfModule”. This rule will only be applied if no file or folder can be found for the URL. If that occurs, the request will be passed to WordPress before providing the client a response.

While this breakdown may be enough of an explanation for some, this is still a very complex chain of rules. The rules are best described and summarized as this: “If Apache itself cannot find the file or folder requested then the request should be dealt with by WordPress directly.”

An interesting result of this is that technically all WordPress pages are a 404 result in the context of Apache and only until PHP and WordPress receive the request can any content be resolved for a response.

Tips for Custom Rules

There usually is not a consistent cause for issues experienced when dealing with .htaccess rules on a WordPress site. As the cause can fluctuate from site to site, and even rule to rule, it’s hard to provide an extensive explanation for the issues. It is also important to note that plugins and themes can also affect how certain rules are managed as well.

A common rule that causes odd behaviour and provides mixed results usually relates to allowing access based on specific IP address. These rules usually look like:

<Files wp-login.php>
Order deny,allow
Deny from all
Allow from localhost

The rule above will deny all IPs access to wp-login.php unless the IP is listed in the ‘Allow from’ line. While it should work by default, occasionally this can cause issues. If it does, the usual fix is to define the error documents. This would look like:

ErrorDocument 401 default
ErrorDocument 403 default
<Files wp-login.php>
Order deny,allow
Deny from all
Allow from localhost

Having these error documents defined explicitly will ensure that when an unapproved IP attempts to access the page they are rejected and are sent a proper error page.

As there are various issues that can come up and each has their own solution, we simply cannot cover them all here. If you believe you are experiencing configuration issues related to those rules mentioned here feel free to contact our Heroic Support®.

What’s New in WHM 58 & What to Look For

In the 58 update of WHM & cPanel several rather large changes have been made to improve upon user experience and to expand available features. As cPanel works to continually expand and improve their offerings, we like to do our best to keep everyone informed and updated. Here are some of the highlights and items to look out for as the 58 update moves to release tier.

What to prepare for?

When large WHM updates, similar to this one, are released, there are often certain items that may exclude a server from being eligible for the update. These are often referred to as ‘update blockers’ within the official documentation. The items here are changes related to these ‘update blockers’.

  • CentOS 5 & CloudLinux 5 are no longer supported by WHM on and after update 58
    • CentOS 5 itself, and therefore CloudLinux 5, are becoming end-of-life status on March 31 of 2017, due to this and software limitations that these OS’s cause, cPanel is removing support preemptively.
  • Servers’ processors must now support 64-bit processing
    • Any older servers with 32-bit (x86) processes will no longer be supported by cPanel/WHM.
  • For a more detailed list of Upgrade Blockers please see: https://confluence2.cpanel.net/display/ALD/58+Release+Notes
  • These update blockers will require a migration in order to update to WHM 58: Feel free to contact our Heroic Support® if you are experiencing these blocks.

What is new?!

On this release cPanel has included a lot of highly-requested features and improvements. This provides for a lot of new opportunities, but with so many changes, it’s easy to lose track of all the great new features that were added. Here are the highlights:

  • Addon Domain to account conversion tool
    • With this new feature you are now able to easily convert an Addon domain into a full-fledged cPanel account.
  • Roundcube is now provided via RPM’s
  • Support for Dovecot’s mdbox storage format
    • Previously email files were stored on a ‘flat file’ manner, one file for each email. Now a user’s complete email storage can use the mdbox file format.
    • For users with large numbers of emails this should help reduce issues and concerns about using up too many disk Inodes.
  • Dovecot now supports email subaddresses
    • Email users can now append their address in a manner that will automatically deliver a message to a specific folder.
    • E.G.: username+Important@email.com will deliver a message directly to the ‘Important’ folder for the username@email.com address.
  • EasyApache 4 has been released
    • It is the default on new WHM installations
      • Existing servers will need to upgrade manually, once upgraded this cannot be reverted.
    • Now fully supports PEAR and PECL
    • EasyApache config tools have been completed as well
      • Provides useful tools to manage EasyApache 4 profiles
    • PHP-FPM support is now included, although it’s not fully refined yet and must be activated outside of WHM.
      • Contact Heroic Support for assistance on setting up and deploying PHP-FPM.
  • Multi-PHP Manager released
    • With EasyApache 4 being released the new Multi-PHP manager has been completed as well.
    • Servers can now operate while providing multiple PHP versions with ease.
  • PHP 7 is now supported and provided via EasyApache 4
  • AutoSSL
    • Free domain-validated SSL certificates are provided by cPanel (powered by Comodo)
    • As of WHM version 58.0.17, and above, AutoSSL now supports Let’s Encrypt as an SSL provider; for more details, see our KB article here.
Free cPanel-provided hostname SSL’s have been provided since WHM release 56 as well.
  • WHM now provides Composer by default
    • Composer is a dependency management tool for PHP-based projects, used frequently in the development and deployment of PHP-based apps, sites, or projects.
    • The WHM provided version does support Composer’s internal update mechanism to stay updated.

What has been changed?

Based on user feedback cPanel will make changes to presets, or default settings, as well as providing updates for 3rd-party tools included in WHM. This section encompases these types of updates.

  • Munin has been updated to provide the 2.0 version
    • Munin is a free system, network, and infrastructure monitoring tool.
  • Reject SPF failures is now enabled by default.
    • This will ensure that servers are checking incoming mail for valid SPF records and will reject Emails which result in a failure.
    • Provides an easier setup for WHM and helps prevent spam.
  • Prevent ‘nobody’ from sending Email now enabled by default.
    • Apache traditionally runs as the ‘nobody’ user and this change to the settings will ensure that by default servers are secure from Apache sending mail.
    • Helps to prevent compromised or unsecure sites for sending outgoing spam.
  • Dovecot now functioning as the local mail delivery agent
    • Exim will now receive inbound messages, connect to Dovecot via LMTP (Local Mail Transfer Protocol) and then deliver the messages.
  • WHM’s internal version of PHP has been updated

What has been removed?

cPanel will often remove redundant, legacy, or unneeded items or features; some of those to keep an eye out for are:

  • Removed ‘Mailserver Selection’ page from WHM
    • In previous releases WHM removed support for Courier and as such this screen is now unused.
  • Bandmin has been removed
    • Bandwidth usages can still be seen and monitored in:
      • Home >> Account Information >> View Bandwidth Usage, or
      • Home >> Metrics >> Bandwidth
  • Stunnel support has been removed
  • Security Advisor has been removed – check on new vs. existing

For more information and details on the various changes coming in the 58 release of WHM and cPanel, please see the official release notes here: https://confluence2.cpanel.net/display/ALD/58+Release+Notes

If you have any questions or are not comfortable making these changes yourself, please feel free to contact Heroic Support®.

How To Boost Web Server Performance with Nginx and Apache

Apache is the most commonly used web server software on the Internet, and for good reason.

Its long history, general reliability, thorough documentation and active support community have helped it grow to include support for nearly anything a web developer can think to throw at it. But Apache’s universal support has not come without some trade-offs.

Why Apache Alone May Not Meet Your Needs

Apache excels at serving web pages, but its resource requirements (particularly memory) increase as it’s given more to do, thanks to the way Apache manages processes. Apache’s process management is governed by its Multi-Processing Module (MPM). The most common are prefork, worker, and event.

Each time a new request comes in, Apache creates a new process to handle it.

  • In prefork mode, each process contains a single thread (the code which runs inside of a process).
  • In worker mode, each process can contain multiple threads, each handling a single connection.
  • In event mode, each process can contain multiple threads, but each is able to handle more than one connection at a time.

Regardless of the MPM, new processes still are being created to handle new incoming requests (although worker creates fewer than prefork, and event creates fewer than worker).

As requests keep coming in and new processes are created to handle them, CPU and memory usage continue to increase. That drives up load, slows the server down, and ultimately (should the amount of incoming requests far exceed the server’s capabilities) could cause it to become unresponsive. With Apache, scaling up typically requires adding RAM or CPU cores to cope with greatly increased traffic.

And that’s the essential problem Nginx aims to solve: Scalability.

Unlike Apache, Nginx does not create new processes to handle incoming requests. It runs with a set number of processes, typically only one per CPU core, and each of its few processes uses a single thread to handle many requests (potentially thousands) at the same time.

Because of this, Nginx’s resource requirements don’t tend to increase with incoming requests as do Apache’s. And thanks to its small footprint, it’s also able to do the job considerably faster.

One Server’s Weakness Is Another’s Strength

While Nginx’s processes management can be much more efficient and it can serve pages at lightning speed, it’s important to note that the potential performance gains with Nginx are most dramatic when serving static content.

That’s because, unlike Apache’s all-in-one approach, Nginx can serve only static content natively (html, images, javascript and css, etc.). To keep it as lightweight as possible, Nginx relies on separate applications such as PHP FastCGI Process Manager (FPM), Tomcat, or Apache to serve dynamic content.

Unless your site is mostly comprised of static pages, you may decide that there’s not a tremendous amount to be gained by switching from Apache to Nginx outright, given that you’d still need to rely on another application to serve the dynamic content.

And that’s the beauty of using the more-powerful Apache and the more-nimble Nginx together.

In terms of resource usage, Apache doesn’t really care what type of content it’s serving. Processes are created and threads are spun off based only on the number of incoming requests. That makes it somewhat less than ideal for serving extremely large amounts of small, static resources.

By allowing Nginx to serve the static content and pass requests for dynamic content to Apache, you can (for a small amount of overhead up front) effectively eliminate the drain on resources that otherwise would have been caused by having Apache serve all that static content.

Meanwhile, Nginx is caching as it serves, making future requests that much faster still.

This setup, in which Nginx listens on the standard web port (typically 80) and transparently passes requests to the appropriate server, is called a reverse proxy configuration.

Depending on your site’s composition and the number of static resources served, you could find that pairing Nginx and Apache can yield dramatic results.


  • Apache, assuming it already is installed and running, would need to be configured to run on another port.
  • After switching the Apache port, sites on the server would not be accessible at their normal URLs until Nginx is installed, properly configured, and running.
  • Nginx handles virtual hosts (vhosts) differently than Apache, and each existing virtual host entry would need to be recreated for Nginx.
  • Some control panel software, such as cPanel/WHM, does not officially support Nginx (although WHM/cPanel plugins are available).
  • The installation, configuration, troubleshooting and maintenance of Nginx is not supported by Liquid Web on any platform; do not attempt to install any software or modify any configuration files unless you have fully researched the process and know how to address any potential issues that may arise.

Find More Information in Our Knowledge Base