Frequently Asked Questions

The NearlyFreeSpeech.NET FAQ (*)

Customization (*)

What canonical name redirection settings are available?

We support two canonical name redirection settings:

off - Our system 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 WordPress multi-site hosting, or if you want to use our per-alias document root feature to host multiple websites using only one site on our system.

on - If anybody accesses your site using an alias other than its canonical name, will automatically, transparently get a "301 Moved Permanently" redirect to the correct name. This setting is particularly appropriate for sites with one correct name, but a number of other aliases that the site owner also wishes to accept.

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 "Edit" button on the "Canonical URL" line.

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 enable canonical name redirection to a name that is different from what your software is expecting. If you don't, your software and our system will get into a slap fight over what name is correct, and all visitors to your site will get is a "too many redirects" error.

If that happens, switch the canonical type back to "off" to let your site load and regain access to your software's administration area. (To continue with the WordPress example, the "blog URI" or "WordPress address (URL)" is the software setting in question.)

For more information about canonical names, see this FAQ entry.

(The "on" setting used to be "hard," so if you see any references to "hard canonical," it means enabling canonical name redirection. We also used to have a "soft" setting, which some old sites still have. It's useless and if you see it, you should get rid of it!)

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 www.example.com or your-site.some-other-web-host.com, 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. Create a one-line plain text file on your local computer called htaccess.txt containing the following (replacing www.example.com with the name of the site you want to forward to):

    RedirectPermanent / http://www.example.com/

    or (if appropriate)

    RedirectPermanent / http://www.example.com/your/custom/path/

  4. Upload this htaccess.txt file to your examplefwd site hosted here as a text file.
  5. 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 members.example.com visitors to www.example.com/members/ and someone visits http://members.example.com/page.html they will be forwarded to http://www.example.com/members/page.html.

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.

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.

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 typically 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, or if you have a custom server type with improperly-configured daemons or proxies.

What should my site's canonical name be?

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

The default canonical name of each site is its nfshost.com alias. If your site's shortname is example, then its default canonical name is example.nfshost.com.

Having a canonical name is especially important when you want to have a bunch of alternative names for the same site. For example, if your website is for Example, LLC, you might want to have www.example.com, www.examplecompany.com, and www.example.biz all point to the same site. You may even want to have www.awesome-widget.com for your awesome widget. Plus all those without the www in front. Knowing and setting one of those names to be the canonical name for your site and enabling canonical redirection can improve your search rankings.

We encourage (but do not require) you to use www.example.com as a canonical name rather than example.com in most cases. See this FAQ entry for an explanation.

For more information on aliases, see this FAQ entry.

What is a per-alias document root?

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

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

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 via 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 nothing protects https://www.example.com/one/ from the contents of https://www.example.com/two/, there is nothing between https://one.example.com/ and https://two.example.com/ if they are pointed to the same site by this feature.

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 (10.20.30.40/24).

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 blocked.nfshost.com, which blocks all visitors.

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

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 "HTTPS Redirection" 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 always set Strict-Transport-Security "max-age=3600;" "expr=%{req_novary:X-Forwarded-Proto}=='https'"

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.

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 www.example.com and another.example.org). 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).

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:

#!/bin/sh
exec /home/protected/bin/mydaemon.py --port=12345 --run-in-foreground

(The above is a fictional example; it is not a valid command. You will have to customize it for however your specific process specifies what port to use and to stay in the 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 myrun.sh)

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."