Frequently Asked Questions

The NearlyFreeSpeech.NET FAQ (*)

Customization (*)

What canonical name settings are available?

NearlyFreeSpeech.NET supports three types of canonical name settings:

off - This is the default type for new sites. The network attempts to avoid the use of a site's canonical name. Redirects issued by the network will use the hostname presented in the HTTP Host: header. From an application standpoint this means that the HTTP_HOST variable will be copied to the SERVER_NAME variable for each request. This setting is particularly suited to sites that vary their content based on which alias is used, such as Drupal or WordPress multi-site hosting.

soft - This type is no longer available; it is only applicable to sites already using it. The network will use the site's configured canonical name when needed, such as during redirects, but will accept requests for any other alias and deliver them if possible. The SERVER_NAME variable will contain the configured canonical name. The use of this setting is not recommended.

hard - The network will always use the site's configured canonical name. If a request arrives for a non-canonical name, the network will automatically, transparently issue a "301 Moved Permanently" redirect to the browser, causing it to switch to the correct name. This setting is particularly appropriate for sites with one correct name, but a number of other names that the site owner also wishes to accept.

The default canonical name of each site is its alias. If your site's shortname is example, then its default canonical name is This is usually only relevant if your canonical type is not off.

Your site's canonical name and type settings are visible in the "Config Information" box on the Site Information page for that site. To make changes to your site's canonical name or type settings, use the "Set Canonical Name" action on the same page.

NOTE: Be sure you have already created the desired alias(es) and specify which alias is to be the canonical name, when requesting the "hard" type. See this FAQ entry for more information.

How do I enable directory indexes for my site?

By default, you must create an index file for each directory that you create. This is a security precaution for novice webmasters to protect them from unintentionally exposing files they did not intend to publish.

The index file can have any one of several names:

(If more than one of these files exists, the server will use the highest one on the list. These names are case-sensitive. E.g. INDEX.HTML and Index.html will not work.)

If you want the web server to display a list of files in a directory, you add the following line to your .htaccess file for that directory:

Options +Indexes

Note that this directive applies to the directory containing its .htaccess file as well as any and all subdirectories.

How do I create a website for the sole purpose of forwarding visitors to another website?

Here are the step-by-step instructions:

  1. Create the forwarding site. If you are going to forward to or, try to give it a short name like examplefwd.
  2. Set up the name you want to forward from as an alias of the examplefwd site.
  3. To save money, set the server type to "Static" server type.
  4. Create a one-line plain text file on your local computer called htaccess.txt containing the following (replacing with the name of the site you want to forward to):

    RedirectPermanent /

    or (if appropriate)

    RedirectPermanent /

  5. Upload this htaccess.txt file to your examplefwd site hosted here as a text file.
  6. Rename the file from htaccess.txt to .htaccess. (That's "htaccess" with a period in front.)

This approach works for all sorts of URLs, not just the main site. For example, if you use this technique to forward visitors to and someone visits they will be forwarded to

Please note if the target site is hosted here and you merely want to redirect alternative names, setting a hard canonical name is usually faster, easier, and cheaper than this approach. This approach is better suited when the redirection involves two hosts or path manipulation at either or both ends.

What should my site's canonical name be?

It's the name you plan to use when someone asks you for the address of your web site; the "official" name. This would typically be something like, and must be one of the aliases that is associated with your site (this can include the default alias ending in

Note that if you are running software on your site that lets you designate the official URL for the site (such as WordPress), you'll need to update that information before you set a hard canonical name that is different from the hostname you have configured for your site. (To continue with the WordPress example, the "blog URI" or "WordPress address (URL)" is the setting in question.) If you don't, you'll probably create a redirect loop and your site won't load anymore. Switch the canonical type back to "off" to let your site load and regain access to your software's administration area.

For more information on this subject, see this FAQ entry.

For more information on aliases, see this FAQ entry.

How do I change the text displayed for missing pages and other errors?

NearlyFreeSpeech.NET provides a basic error page in response to most common types of site errors. Sometimes, you may wish to override these pages and provide your own error messages that fit your site style or provide additional information. In order to do this, add the following line to the .htaccess file in your public directory (you'll need to create this plain-text file first if you don't have one):

ErrorDocument 404 /err404.html

Where 404 is the number of the error you wish to catch and err404.html is the name of the file you want displayed when an error occurs. You may use a PHP or CGI script for an ErrorDocument, but be careful not to use absolute paths to specify the name of your ErrorDocument.

Here are the most common errors:

Due to the design of our network, you cannot use an ErrorDocument to catch a 503 Service Unavailable error. Such errors do not routinely occur except during system maintenance. They may also occur during some types of partial service interruptions.

When should the rewrite log be used?

The syntax for mod_rewrite rules can be tricky and hard to get just right, especially as they get more complex. The rewrite log can help debug RewriteRules. However, as soon as you debug your rules, it's very important to turn it off.

Because a single rewrite rule can produce several lines of output, the rewrite engine obtains a lock on the rewrite log for each access. This means your site can only process one access at a time, which is a horrible performance penalty.

Worse than that, we have seen Apache occasionally lose this lock if an in-progress request dies during rewrite processing (for example due to a closed connection), which will cause all requests for your site to stall indefinitely until the server won't accept any more.

For these reasons, you absolutely should not run the rewrite log on a production site, or for any longer than absolutely necessary to debug your rewrite rules.

What path should I use for .htpasswd files?

Due to the internal security requirements for the Apache web server, .htpasswd files must be referred to by an absolute path. To find this path for your site, check the "Apache Site Root" value in the "Config Information" box on the Site Information page for your site.

For example, if you have a site named example and the .htpasswd file is in your site's /home/protected directory and your Apache Site Root value is /fsxx/example, your .htaccess file might read:

AuthType Basic
AuthName "My Restricted Website"
AuthBasicProvider file
AuthUserFile /fsxx/example/protected/.htpasswd
require valid-user

Although it should be impossible to retrieve an .htpasswd file using web access*, the Apache documentation recommends that you do not store .htpasswd files inside your document root. This is why we recommend using the protected directory instead. Whatever its location, an .htpasswd file must be world readable (or, at least, readable by group "web").

*Only the specific filename .htpasswd is protected from web access. If you use password files with other names in your public directory, they may be visible from the web, which is bad.

How do I restrict which IP addresses can access my site?

Due to the way our network handles incoming requests, it is not possible to use .htaccess files to block IP addresses from accessing your site; by the time the .htaccess file is considered, the incoming request has already been accepted.

However, we recognize the common desire to restrict accesses in this way. For this reason, we provide the ability to block accesses on a per-site per-IP basis at the edge of our network.

By default, all accesses are allowed. We maintain two lists for each site, an allow list and a deny list, which are processed in the order: allow, deny. Thus, an IP address that appears on both lists will be allowed. Entries to either list can contain either an IP address or a netblock specified in CIDR format (

You can see and manipulate your site's IP access controls (if any) in the "Config Information" box on the Site Information page.

To see exactly what blocked visitors see, visit, which blocks all visitors.

Please note that IP access lists currently do not work in conjunction with TLS; due to the front end TLS wrapper we use, all requests appear to originate from

See also What do I do if someone is trying to waste my site's bandwidth?

How do I mark my site as static content so I won't be charged for CGI/PHP on a site that doesn't use it?

To change the server type on your site to static -- thereby avoiding the $0.01/day charge for sites that support CGI & PHP -- please see this entry.

Note: If your server type is identified by our system as "HTStatic" or "Static Content - .htstatic" it is an older type (no longer available) that uses .htstatic files instead of .htaccess. If your server type is "Static" or "Static Content - No PHP or CGI," use .htaccess files as normal.

Can I set up more than one alias for my site?

Yes. Our servers support having more than one alternate name for your site (such as and If you visit the Sites panel and then select your site name in the "Short Name" list, you will see the Site Information page, where you can add and remove aliases at any time.

You may also add NearlyFreeSpeech.NET DNS to an alias at any time by visiting the Domains panel and choosing "Add" under the "DNS" column for the relevant alias (domain).

What is a per-alias site root?

Ordinarily, your site's document root (as seen by Apache) is /home/public. If you enable the per-alias site root feature from the site info panel in our member interface, the alias being used will be added to the site root.

For example, if you have configured as an alias for your site, then when someone visits it Apache will treat /home/public/ as the document root. If you also have the alias added to the site, then requests using that alias will be directed to /home/public/

If no directory exists for a given alias, all requests for that alias will return 404. If a directory exists but no alias has been added in our UI, it will not be recognized as an alias.

This feature can be very helpful if you have multiple sites that need to share some but not all of their data, or if you have several sites with different content that are all based on a common framework. Using this feature can allow you to maintain one copy of the framework.

This feature is not a substitute for creating multiple sites. With this feature, one site is still just one site. There is no additional security, isolation, or protection implied by using this feature. Just as there is nothing protecting from the contents of, there is nothing between and if they are pointed to the same site by this feature.

How do I control redirection of HTTP visitors to HTTPS?

Once you have TLS working for your site, visitors to the HTTP version will be redirected to the HTTPS version by default, but you can control this behavior from our control panel.

  1. Go to the Site Information panel for your site.
  2. In the "Config Information" box, select the "Edit" button on the "Canonical URL" line.
  3. Set the Canonical HTTPS value to "on" if you want HTTP visitors redirected to HTTPS and "off" if you do not.

(Don't worry, this setting does not apply to any alias of the site that is not set up for TLS.)

You can also optionally indicate strict transport security. However, we don't recommend doing this unless you understand what it's for and how it works. If you get this wrong, you could potentially lock visitors out of your site for six months. The benefit is that if you do this, it will inform browsers to automatically use HTTPS to access your site, even if someone types in an http:// URL.

If you want to do this, add a line to an .htaccess file in your site's public directory something like:

Header set Strict-Transport-Security "max-age=3600;" "expr=%{req_novary:X-Forwarded-Proto}=='https'"

(Note: The above command only works with Apache 2.4 and later. If you're still using an Apache 2.2-based server type, this would be a good time to upgrade.)

Once you are very, very sure everything is working properly, you can change the 3600 to 15552000 and optionally add "includeSubDomains" after the semicolon to improve the rating of your site's security on sites like SSLlabs. However, be very careful in doing so, as this value represents 180 days, and if you make a mistake such as redirecting people to an HTTPS version of an alias that isn't set up for HTTPS, you can potentially lock them out of your site for that length of time.

How do I change the server type my site uses?

  1. Go to the Sites panel.
  2. Select the name of the site to go to its Site Information panel.
  3. Scroll down to the "Config Information" box on the Site Information panel.
  4. Click the "Edit" button on the right side of the "Server Type" line in the "Config Information" box.
  5. Select your preferred server type and choose "Save Changes."

How do I make my site fast and scalable?

This can be very difficult. We wish we could push a magic button and take care of it for you, but the truth is that the scalability and performance of your site is much more under your control than ours. When sites encounter performance issues (such as 503 errors) under load, we almost always find that it is some problem with the site's programming that is responsible. Based on our extensive experience with such situations, we have prepared some general guidelines to help you design a site that is fast and scalable and remains available under heavy load.

First, if you are running WordPress, this information will not be much help. Basic WordPress installs are hopelessly incapable of surviving traffic surges. It requires extensive, specialized tuning to have a WordPress site that remains available under load. We recommend that you read and follow our Advanced WordPress Configuration guide, but even that is mostly in the nature of a good start.

For applications you are developing yourself, the following information may be helpful.

Building scalable web sites is a high art, and the tips shared here only scratch the surface. But hopefully they offer a place to start on the long, hard journey to building a site that can handle hundreds of thousands of simultaneous users and dozens of requests per second. (And yes, we host those types of sites.)

What is a run script?

If you configure a site type that supports arbitrary daemon processes, the infrastructure that initializes them does not process command line arguments. In the rare case that you don't need any, you can run the daemon executable directly from the 'Command' field of the Daemon management interface. In all other cases, you will need a run script.

A run script is a short shell script that lets you customize the environment for your daemon without worrying about the massive stack of stuff we have to do to make sure your daemon runs in the context of your site. A typical, minimal run script is an executable file that looks like this:

exec /home/protected/bin/ --port=12345 --run-in-foreground

Then, you enter the path to the run script as the command in your daemon configuration. This lets you customize the daemon's command line arguments. You can also take other actions if needed, like setting environment variables, removing temporary files from previous runs, running preflight database checks, etc.

When writing run scripts, always make sure the following key elements are present:

  1. The shebang line is the first line of the run script. (#!/bin/sh)
  2. The exec command in front of the daemon executable. (Saves RAM = lower costs, may also avoid problems with signal delivery.)
  3. The daemon must run in the foreground. (Otherwise it will be repeatedly killed and restarted.)
  4. Starting the daemon is the last line in the run script. (Anything after that will almost never be run.)
  5. Executable permissions on the run script. (chmod a+x