Frequently Asked Questions

The NearlyFreeSpeech.NET FAQ (*)

Troubleshooting (*)

How should I describe problems I'm having when seeking help with them?

When you encounter a problem that you think may be related to our service, we absolutely want to hear about it so we can fix it or help you get it fixed.

However, in order to help you, we need certain information. If all you tell us is that something is "down" or "doesn't work," you are severely limiting our ability to troubleshoot the problem. This is compounded if you say "my site" or "the service," and that's even more true if you host more than one thing with us.

First and foremost, if the problem you're experiencing involves an error message, absolutely, positively, do not omit or paraphrase the error message. Include the full text of the error message. If you don't, you'll wait around for us to respond, and our response will be "what's the full text of the error message you're receiving?" (Or, possibly, a link to this FAQ entry.) That's wasted time, which is no good if there's really a problem.

If there is no error message, but something doesn't work the way you expect, then carefully explain what you're doing, what you expect the results to be, what the results actually are, and how the actual results differ from your expectations. Be absolutely as specific as possible; things that may be obvious to you often won't be to anyone else unless you mention them. As with error messages, cut and paste any relevant output, configuration data, log entries, or related information -- do not paraphrase or summarize it.

Second, make sure you've read the error message. Many of the error messages produced by our system include specific explanations or lists of reasons why they occur, and it's painful for us to see someone's service disrupted for a reason they could fix at any time.

Third, make it really clear what site (including a specific URL if possible), service, functionality, or email address you're having a problem with. If you don't, particularly if there's more than one possibility, you'll lose more time while you wait for us to ask for clarification.

Fourth, outline what steps that you've already taken to try to identify the problem. Recognize that we control only a limited portion of the Internet; ISPs control part, backbone carriers control others, and you control the stuff on your end. Help us understand why you think the weak link is in our portion of the chain. For example, the Site Troubleshooting Wizard can't solve all problems, but it does identify a lot of weird domain and DNS related issues related to sites hosted here, so it'll help us to know if you've tried that and what the result was.

Finally, if you're asking about an error on your site that may be related to accessing a CGI or PHP script, or if you have a complex .htaccess file, make sure you have your error log enabled. It's disabled by default to save space, but it's an invaluable tool for identifying and resolving many types of problems.

Our goal is for all of your services and all of our systems to be working properly at all times. If something's not right, we want to hear about it. But please help us help you; give us the information we'll need to confirm, troubleshoot, and resolve your problem. Keep in mind that we often have to triage requests, so that people with problems under our control get priority. If you structure your request along the lines shown here, it may help us spot yours as one that needs more immediate attention.

Why can't I delete or change the permissions of these files my web application created?

As a security precaution, CGI and PHP scripts run with different user credentials than you do when you edit your files. Although the CGI/PHP user has significantly fewer privileges overall, it is possible to create a situation where an application creates files or directories that you do not have permission to access or remove via FTP or ssh. This typically happens if an application's umask is set incorrectly; the resulting files or directories will be owned by the "web" user and will not be group or world writable. (Correct umasks are 0 or 002, depending on the expected group ownership. A umask of 0 should work for most web applications, and does not compromise security on our system the way it does on some shared hosts.)

If you get stuck with web-owned files you can't access or delete, you can regain control using the "Repossess Files" action on the Site Information panel for the affected site. However, if you find yourself doing this on a regular basis, that tends to indicate your site's permissions aren't set properly.

If I have a directory called example, why can't I refer to it as /example?

This is a restriction imposed by Apache. It is designed to prohibit ambiguity in determining which access controls apply to the directory.

Assume your public directory contains a subdirectory called example. If you access it via /example, you have not entered that directory. That means that the .htaccess file from your public directory would be applied, but the .htaccess file inside the example directory would not. However, if you access it via /example/, then you have entered the directory and both .htaccess files will be applied.

Now, assume that your public directory's .htaccess file allows all visitors and has directory indexing enabled. Assume that your example directory's .htaccess file allows only visitors with a certain cookie set and denies directory indexing. In this case, if it were allowed, visiting /example would produce a listing of the contents of the example directory while visiting /example/ would produce an access denied error or demand for authentication.

To prevent the confusion and security issues that such conflicting behavior would create, Apache detects attempts to access directories without trailing slashes and automatically issues a redirect to the same URI with the trailing slash appended. That way, you never have to worry about the scenario in the preceding paragraph.

Although you can't stop people from typing one in by hand, make sure you don't use invalid directory URIs internally on your site because they require this extra redirect, thus making your site appear slower.

If you find that these redirects are not using the site alias that you want, for example, if they redirect you to instead of, then you may need to adjust your site's canonical name settings.

Why does my site keep redirecting to the wrong alias?

There are a couple of possible explanations for this.

  1. Your site may be configured to do so. WordPress, for example, may default to using the wrong name and needs to be manually informed under the General Settings in the WordPress Admin panel sidebar to use your real domain name. If the General Settings tab is unreachable, you can also change the site name from the command line with the commands:
    YourPrompt> wp option update home
    YourPrompt> wp option update siteurl
  2. You may be entering an invalid directory URI or something else that causes the network to redirect you. In this case, the server may not be using the name you expect in the redirected URL. (This primarily afflicts sites created prior to April 6, 2008.) If you have problems of this nature, make sure you have appropriate canonical name settings for your site.

What does it mean that a site "has temporarily exceeded its connection limit?"

This error (also frequently seen as "503 Service Unavailable" or "The requested website is temporarily not available due to a resource limitation.") means there are too many total simultaneous non-cacheable HTTP requests in progress for your site. This is an extremely rare condition, but the causes, in order of decreasing likelihood, are:

  1. For sites like CMS or blog sites that generate content dynamically, a spammer, email address harvester, or lousy web spider attempts to hit all or a large number of the site's dynamic pages at once. Our system will throw up this error to dissuade the spammer and stop them from dragging the whole server down. In this case, the message will typically only appear for a few seconds to a couple of minutes; as soon as they start getting errors, they usually move on.
  2. This message can also occur if requests for your site content hang or take an inordinately long time to complete. In such cases, they can backlog to the point where the server feels that allowing more of them to build up would just cause a death spiral. (I.e. more requests taking longer causing more requests to take even longer, wash-rinse-repeat until nothing happens at all).
  3. Under exceptionally rare circumstances, this message can indicate that the server that hosts your site is having severe problems. Such conditions are automatically detected and we are notified, so they tend not to persist for very long.
  4. If your site has several hundred simultaneous visitors for sustained periods of time, it's remotely possible to hit this limit even if your connections complete very quickly. In this case, and only in this case, we will raise the limit, because this limit provides your site with important protection against all the other cases.

Please be aware that while almost everyone starts out thinking #4 is the reason that applies to their situation, the cause almost inevitably turns out to be something else. A good rule of thumb is that each possible explanation above is about ten times less likely than the one above it, so the top one is 90% likely and the bottom one is about 0.09% likely.

If this message persists long enough to cause problems, the explanation is most likely the second one. In that case, the way to troubleshoot it is to identify and resolve the cause. Coding problems that can cause this include, but aren't limited to:

Some poorly-written WordPress and Drupal plugins have been known to cause these sorts of problems under heavy loads, particularly ones that deal with statistics or running periodic scheduled tasks.

If you have a subscription membership and submit a secure support request while the problem is occurring, we can typically identify the problem URLs for you, and may be able to give you some insight as to what they are waiting for. After the fact, it may be possible for you to get some idea of what happened by looking at your site's access logs, if they were enabled.

Please keep in mind that this limit is not some nuisance we put in at random to cause problems for our members. It is a crucial protection that keeps your site (and others') safe and available. When someone says they want it removed, we hear: "My car would go a lot faster through the mountains if it didn't skid along the guardrail every time I go around those hairpin curves! Take that guardrail out!" We know from experience that if we take out the guardrails, the car won't go faster; it will fly off the side of the mountain and end in a fiery crash. You may be willing to take that risk with your site, but since ours is a shared hosting service, we can't risk letting you take others down with you. If you want the limit raised, be prepared to show us ample concrete evidence documenting both your sustained high traffic levels and the excellent performance of your highly-optimized code.

I can't access my site at all. What should I check first?

Our Site Troubleshooting Wizard may be able to help. It is pretty good at detecting site problems, DNS misconfiguration, and domain registration errors.

If that doesn't work, you haven't changed anything that may have caused this, and there is nothing listed in the announcements about something wrong right now, please contact support and provide as much information as possible about your problem. Be sure to include the name of the site you are reporting trouble with!

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

You have several options.

First, we always recommend that attack-prone sites minimize their attack profile by consciously examining the use of large files. One good example of this is using graphics compression to make images smaller, or to evaluate whether that one graphic really needs a 24 megapixel click-to-zoom version.

These steps are primarily useful if your site is attacked by a large number of different addresses, or if the addresses used change rapidly. (It's also a good way to save money and ensure a fast-loading site in the far more common not-being-attacked case, including high-usage periods like getting mentioned on Reddit.)

Second, you can edit your site's IP access controls. This is the most efficient way to block access to your site in that it will have the least performance impact on legitimate visitors. However, our system IP access controls are general purpose and not specifically designed for abuse. Therefore they return a small error message to visitors, and that still takes up some bandwidth; an attacker blocked by our IP access controls would have to hit your site about 820,000 times to use a gigabyte of bandwidth.

If you're sure someone is attempting to waste bandwidth, there is a third option you can use to eliminate as much of the response as you can. Take the following steps:

  1. Create a zero-length file called "no" in your site's public directory. (E.g. touch /home/public/no from the ssh server.) Do not skip this step!
  2. Add the following to your .htaccess file (replace with the IP address to block):
    RewriteEngine on
    RewriteCond %{HTTP:X-Forwarded-For}
    RewriteCond %{REQUEST_URI} !=/no
    RewriteRule .* /no [L]

Affected visitors will receive an empty "OK" response. This still includes HTTP headers, but that's all. An attacker blocked by this would have to hit your site about 3,600,000 times to use even one gigabyte of bandwidth.

There is a variant of this that saves slightly more bandwidth and may fool would-be attackers into thinking they have succeeded in taking your site down. However, it carries an additional risk: It bends the HTTP standard, and if you do not set the IP address properly, search engines who see this response will also think your site is gone and remove references to it. The code for .htaccess is (again replacing with the IP address to block):

# Do not put this in your .htaccess unless you have read the warning above.
RewriteEngine on
RewriteCond %{HTTP:X-Forwarded-For}
RewriteRule .* . [L,G]
ErrorDocument 410 "."

This returns an HTTP "410 Gone" response and one byte of content. This has the side effect of eliminating some HTTP headers. As a result, an attacker blocked by this would have to hit your site about 4,600,000 times to use up a gigabyte of bandwidth.

If you need to block more than one IP address using the latter two techniques, combine them as in the following example:

RewriteEngine on
RewriteCond %{HTTP:X-Forwarded-For} [OR]
RewriteCond %{HTTP:X-Forwarded-For} [OR]
RewriteCond %{HTTP:X-Forwarded-For}
RewriteCond %{REQUEST_URI} !=/no
RewriteRule .* /no [L]

While the only way to completely protect your site from all Internet attacks is not to put it on the Internet, we hope these options will help you defend yourself in the unlikely event that your site falls victim to a bandwidth-wasting attack.

Why does your credit card form say my address (or zip) "failed validation" even though I know it is correct?

We have no idea. We do not make the determination of whether your address information is correct or not. (We have no way of knowing.)

Our system forwards the address information you provide to your card-issuing bank and basically they tell us "yes that's correct" or "no that's not correct." If your bank tells us that your information isn't correct, then our system tells you that the address information isn't correct. Your bank does not tell us why it is incorrect, nor what they believe the correct information to be.

Consequently, any questions you have about why your address was reported as incorrect should be directed to the bank that issued your card, not to us.

Should you find yourself in this situation, you should also be aware that your bank may place a temporary pre-auth hold on the funds, even though the transaction was declined. Also note that if you call your bank's customer service, it is fairly common for them to see the pre-auth hold and claim (incorrectly) that the transaction was approved without looking into it any further.

You may also encounter this issue if you are using a US-based bank but your billing address is outside the US. We have seen several cases where the banks could get the foreign address right on statements, but where their address verification system was totally unable to cope with it.

If you find yourself in this situation, for whatever reason, you have a couple of options:

Although the above applies mostly to US-based members, and those in other countries with compatible AVS implementations, the UK in particular uses a completely different system. Certain banks in the UK, for reasons we do not fully understand, falsely return that the address (or zip) is incorrect when they should return that they do not support this type of address verification. This error on their part will cause our system to reject your card no matter what you enter for your address details. This affects about 10% of our UK members.

This could happen even if you have successfully used the card other places online in the past. We are not only unusually strict in address verification enforcement to protect our members from fraud, but we are also not large enough to have specialized card processing options for the UK as many huge Internet retailers (e.g. Amazon) do. (We do use Stripe, which is one of the largest and most capable payment processors, and that has really cut back -- but not eliminated -- UK-based complaints about this issue.)

Of course, you can try contacting your bank, but it probably won't help, especially if you are in the UK. The customer service agents simply aren't trained on the intricacies of an address verification system that they apparently don't use. There's somebody deep in the bowels of the operations department of your bank who understands what's going on, but good luck getting them on the phone; we've never had a report that a member successfully accomplished that.

We are very sorry for the inconvenience caused to the handful of our members who run into these kinds of problems. It affects only a few, and is caused by a problem completely beyond our control, but it's still endlessly frustrating.

What does the error message "Zero Sized Reply" mean?

Technically, it means that the web process handling your request closed the connection without returning any data at all, not even HTTP headers. (It sent a "zero-sized reply.")

Unfortunately, there are a number of completely different reasons why this might happen that need to be investigated individually.

If the error message takes a very long time to be displayed (a minute or more), it may just be that the system got tired of waiting for a script or CGI application to respond. In this case, try to identify what's making your script run so slowly.

If the error message appears instantly, it probably means something is aborting the connection. If you receive this error from a CGI script, it may mean that your script (or its interpreter, if applicable) is core dumping.

To help debug this problem, make sure you have your error log enabled. If it happens immediately and there are no error log entries, it may be a core dump. In that case, find a public URL that does it reproducibly and submit it to us in a secure support request; we can check the system logs to find out if requests for that URL are indeed core dumping. If there are error logs, they will probably help identify the problem.

If you are running into this problem on a PHP site, it may help to add the following lines to your .htaccess file:

php_value pcre.recursion_limit 1000
php_value pcre.backtrack_limit 1000

The specific values to use vary from site to site. Some require settings as low as 10, others may be fine with 100000. You want the largest value that you can set without triggering the zero-sized reply. This is caused by a PHP/PCRE bug and is not under our control.

Why shouldn't I refer to my site as "" in the forum?

When asking for help in our forum, we strongly recommend against replacing the name of your site with example or a domain with or taking similar steps to conceal the specifics of what you're asking about.

Obfuscating the details of a question or problem forces people to guess rather than investigate. Guessing is both difficult and inaccurate, so requiring it severely limits both the amount and the quality of help you are likely to get. Remember that requesting help in the forums is free, so anyone who answers you -- whether they work for us or not -- is doing so on a volunteer basis. So, if you're going to ask for free help, it's always a good idea to make it as easy as possible for people to help you, especially if doing so makes it more likely that their help will actually be helpful.

It's also frequently the case that when people obfuscate the details of what they're asking about, they inadvertently omit the information needed to correctly resolve a problem or answer their question. This is perfectly normal, because it's frequently not possible to know what information is needed to solve a problem without knowing the solution to the problem. And if someone already knows the solution to a problem, they usually don't ask for help with it in the first place.

So, when asking for help in the forums, we recommend providing as many specific details as possible, along with following our standard troubleshooting advice. This will almost always help you answer your question or solve your problem faster and more accurately.

There is one case where this is less true: when the content of the site is controversial enough that it may distract people from helping you. If that's the case, or if you feel you have another reason why posting the details of what you are asking about is inappropriate, you are welcome to try asking without them. But, in our experience, those types of scenarios make resolving issues via a public forum much more difficult and unlikely, so our paid private support may yield better results.

Why do I sometimes receive an "Access Denied" error when visiting my site?

Please see this page for complete information on this message and how to eliminate it.

Why am I getting a "premature end of script headers" error when I try to run a script?

This error occurs when a CGI script exits before writing a complete set of HTTP response headers (not even an empty one). It can happen for a variety of reasons:

In all cases, the best thing to do is make sure your site's error log is enabled and see what it says about the problem. If the error output says that there is a system problem preventing execution of your script, or if there is no message in the error log at all, please submit a secure support request indicating the URL of the script you're having trouble with. In many cases, it will be easier to debug a problem if you can provide a simple example at a publicly available URL.

Why doesn't my .htaccess file work with Apache 2.4?

There are a few incompatibilities between Apache 2.2 and 2.4. These are described in detail in the Apache 2.4 documentation.

In most cases, the source of compatibility problems is an .htaccess file. If it is not compatible with Apache 2.4, it will cause your site to return "500 Internal Server Error."

To narrow down the specific cause, we recommend that you enable your site's error log in the member interface (if you haven't already). Once it is enabled, access the site a few times to exercise the error, and then the error_log file in your site's logs directory should point you directly to the problem.

The most common example comes from using the Order directive to restrict access to certain content. It has been completely removed from Apache 2.4, but is still very common in example files and configs distributed with many web applications that haven't been updated yet.

To update a 2.2 .htaccess file containing something like:

Order deny,allow
Deny from all

the 2.4 equivalent of both lines would be the single line:

Require all denied

to deny all access and:

Require all granted

to allow it.

Other 2.2-specific configuration directives that have changed in 2.4 can be similarly adapted. See the Apache documentation linked above for complete details.

Why do I get "The requested URI could not be accessed" when logging in to the control panel of my WordPress site?

If you get a message similar to the following when accessing your WordPress site's control panel:

The requested URI could not be accessed.

Or, for older versions of PHP:

Warning: Unknown: failed to open stream: Permission denied in Unknown on line 0

Warning: Unknown: failed to open stream: Permission denied in Unknown on line 0

Fatal error: Unknown: Failed opening required '.../wp-login.php' (include_path='...') in Unknown on line 0

this indicates that your WordPress login page has been temporarily disabled to protect your site, your wallet (and us, other sites we host, and the Internet at large) from a hostile attacker trying to force their way into your site.

When this happened, an email was sent to you with the full details, including how to resolve the situation. You should have that email. If you don't, stop and make sure your member contact email address is up to date and that your email system is not marking messages from us as spam.

When you next need to log in to your WordPress site, all you need to do is reset the permissions of your wp-login.php script. The recommended permissions for this script are 0644. This is typically done with a command like:

chmod 644 /home/public/wp-login.php

(If your blog is not installed in /home/public, you may have to adjust this.)

You can run this command from the shell or using the "Run Shell Command" action on the Site Information panel for this site in our member interface. You can also perform the same action with whatever SFTP or FTP application you prefer to use to maintain your site files. Just edit the permissions of the wp-login.php file and make sure that it is readable by everyone.

If you have frequent problems with this, you may wish to investigate the security options presented in the "Stopping Login Attacks" and "General Security" sections of our Advanced WordPress Configuration guide.

Why is there a tiny bug icon on a page in the member interface?

This indicates that something unusual happened on that page that the system thinks we need to know about.

We're committed to increasing the quality of our software, so we're constantly implementing new checks and stricter language features. So in almost every case, the "bug" is just the system letting us know that it found something that isn't technically wrong, but could be better. But sometimes, it's a real bug. Either way, we'll be automatically notified, and we'll check it out and fix it.

Most of the time, you can ignore the icon. But if you see one, it's a good indication to double check that everything happened as you expect.

Why do I get a message about "technical difficulties" when making a Dwolla payment?

Sometimes people receive a generic error from the Dwolla site when they attempt to complete a payment initiated from our service. This has nothing to do with us; it appears to be an issue with the Dwolla site itself.

We have had multiple reports that you can resolve it by making sure you are not already logged in to the Dwolla site when you initiate a Dwolla payment from our site. If necessary, you can clear your cookies from the Dwolla site (not from our site) before starting the transaction to make sure you are starting from a clean slate.