There's hundreds of reasons why a website couldn't load, but usually it's pretty easy to narrow it down to a few key reasons.
A good way to start is making sure that your nameservers are set properly. There's two main parts to getting a website online: the domain and the hosting. These don't always automatically link up together; sometimes you will need to tell the domain where your hosting server is. This is done by setting the nameservers for your domain.
Nameservers are formatted as a list of subdomains, and will usually look something like this:
For more information on what the nameservers are for your Arch Hosting account, and how to set them for your domain, please check out this knowledgebase article: https://archhosting.net/knowledgebase/9/What-are-the-nameservers.html
You can look up your nameservers with free tools online, at Arch Hosting we would recommend that you use a tool like whois.net.
Keep in mind that DNS changes, such as updating your nameservers, are not always instant. This process is called DNS propogation, and can take from a minute to 48 hours depending on your network. A good way to speed up this process is by clearing your browser cache and clearing your DNS cache. We'll cover more about this below.
If you've transferred to us from another hosting provider, odds are likely that you will need to update your domain's nameservers from theirs to ours. If your nameservers are not set correctly, your website will not load.
3rd Party Nameservers & DNS Records
If you're using the Arch Hosting nameservers, chances are you can skip this part of the guide entirely. However, for customers who use 3rd party DNS (such as DNS provided by their domain registrar, or Cloudflare) will need to configure their records on their own to point to the Arch Hosting servers. You will need to create A records that point to the IP address of your web hosting server for your website to resolve. At the bare minimum, you will need to create an A record for:
- Create a root A record (leave the name blank, or type "@" if allowed) that points to your server's IP address. This will allow your website to load by visiting the domain directly - for example: mywebsite.com will now point to our hosting.
- Create an A record named "www" also pointed to the same server's IP address. This will allow your website to load by visiting the domain with the "www." prefix - for example: www.mywebsite.com will now point to our hosting.
These two records are the bare minimum to getting your website to load. If you create any new subdomains in your cPanel, you will want to create an A record for each of them. The name for the A record should be identical to the subdomain name, and the value of the record should be the server's IP address.
For clients using third party DNS, keep in mind you will need to review your MX records and SPF/DKIM records if you intend to send and receive mail. You will want an MX record with a normal priority (10), no name (leave it blank, or type "@"), that points to your server hostname. Your server's hostname will look something like this: us-westXX.archhosting.net.
For SPF and DKIM records, you will want to visit the "Authentication" section of your cPanel under the Email settings to identify the correct values to input there. They should be created as TXT records.
MX records are necessary to receive mail, and SPF/DKIM TXT records are required for outbound mail to not end up in the recipient's junk folder.
Caching & Propogation Issues
If you've just recently set up your website, it's very possible that it's still undergoing DNS propogation. As mentioned above, this is a process that can take effect any time you make a change to a domain's DNS records or modify your domain's nameservers. DNS Caching can be an issue in cases like this, because it means your website will still point to your old host and not to the new Arch Hosting hosting servers. It can take up to 48 hours for your network to fetch the new nameserver/DNS updates and load your website properly, however usually the process is much quicker than that.
If you'd like to skip the DNS propogation process altogether and immediately access your website, you should try clearing your DNS cache. This is an easy task to do, and requires accessing your computer's command prompt. There's a very straightfoward guide on how to do this here: https://documentation.cpanel.net/display/CKB/How+To+Clear+Your+DNS+Cache
A great tool to check your domain's current DNS status is https://www.whatsmydns.net/. This will allow you to input your domain, and see which IP addresses your domain is pointing towards. You should reference your welcome email and make sure the IP addresses match the one that is assigned to your server. If the IP address does not match, then it's possible your domain is still undergoing DNS propogation. If 48 hours have elapsed, or you've cleared your DNS cache and the issue persists, then please review your nameserver (or DNS record) configuration and ensure they are set properly.
One often overlooked issue is that it could simply be your browser cache. Try clearing your browser cache completely, and rebooting your computer - this will clear out old versions of your website and force new versions to load.
If your website is successfully pointed towards Arch Hosting, you may still be receiving some errors due to the software/scripts on your website. Common errors that you may receive are:
- Incorrect SSL configuration
- Internal 500 Error
- PHP errors, that can look something along the lines of this: Warning: fopen(welcome.txt) [function.fopen]: failed to open stream: No such file or directory in /home/mywebsite/public_html/test.php on line 2
If you are receiving an incorrect SSL configuration error, then please ensure that your SSL was signed properly. Keep in mind, we don't sign SSL certificates instantly - they are signed nightly, or upon request. More information about that can be found here: https://archhosting.net/knowledgebase/57/How-do-I-get-free-SSL-What-is-your-free-SSL.html
If you are receiving an Internal 500 or PHP error, this means there is something wrong with your PHP script. To begin debugging this, you should first access your File Manager (or use FTP) and navigate to the folder that contains the broken PHP script. For example, if you're visiting mywebsite.com/scripts/test.php then you will want to visit /public_html/scripts. You should look for a file called "error_log" - this is a system generated text file that will read out the cause of the error. Once you identify the error, you can look into resolving it. If this is caused by a plugin if you're using a system like Wordpress, then try removing the plugin. If this is an issue with a custom script, then try contacting your developer to identify the broken code. If this error is because PHP requires a particular module to be installed, identify the module and then create a support ticket and we'll see if we can assist you with installing the module.
If you've recently modified your .htaccess file, then it is a good idea to review those modifications. It's very common that a broken .htaccess file code will result in receiving an Internal 500 error. Try removing the file and seeing if your website will load, and if it does then use trial & error to identify the culprit code.
Additionally, it's good practice to also review the Apache errors when encountering Internal 500 errors. You can view these by visiting the "Errors" section of your cPanel.
If you think your website may be exhausting server resources, you can view this by logging into your cPanel and checking your Entry Processes, Memory, etc. on the information bar on the right. This will show you if anything is maxed out - if you have a PHP script that is hung or leaking memory it may crash and cause these resources to fill up and make your website inaccessible. If this is the case, try removing the script - and if the issue persists let us know and we will hard kill the broken processes for you. If you visit the "CPU and Concurrent Connection Usage" section of your cPanel, you will be able to view if your site has been limited due to excessive resource usage recently. You can also use this tool to identify any excessive resource usage that may be the result of a broken script.
You should also review your PHP script's file permissions. We use the SuPHP handler on most of our servers, so it's worth a try to ensure that the file permissions for all of your .php scripts are set to 644. All directories should be set to 755. If you set a script to 777, it may result in being unprocessable.
If you continue to be unsure why your website is not working, then please contact us and we can help you look into it.
If you are unable to connect to your website at all (Connection refused error or timeout error, usually) and you are not able to connect to your cPanel, then it is possible your IP address was blocked in our firewall. This can happen if the system detects too many failed login attempts in a short amount of time - and will trigger on any service - such as e-mail, FTP, SSH, cPanel logins, etc. If this is the case, it can be resolved easily - just create a support ticket and let us know you believe you've been blocked. Please also mention your IP address, and we can verify if you've been blocked and whitelist the IP address to prevent it from being blocked again. You can determine your IP address by visiting the following page, and checking the "Your IP Address" field: http://us-west01-lg.archhosting.net/
Additionally, keep in mind it could be your own firewall blocking the connection! If you are on a school or work network, contact your systems administrator and see if they block any ports. Port 21 will be required for FTP, and the cPanel login interface is done over port 2083. They may not block port 80 and 443 (required for visiting your website), but if you're only unable to access your admin area or tools like FTP then this could be the culprit. Default Windows firewall systems and antiviruses should not normally block any part of our services by default. If you have any parental controls on your computer, please also review those and ensure ArchHosting.net and associated servers are whitelisted.