If there’s a common denominator for website owners, it’s that everyone has to use a web host. Yes, the lucky and few can host their own servers to run their site, but the vast majority of us pay the monthly trickle fee for some mega-service to host our website.
It’s relatively cheap, leaves the complicated server-running side to dedicated professionals, and allows us free time to actually build and maintain our websites, which is the whole point.
If you’ve arrived at this article it’s likely you’re using, or trying to use, proxies that work with your web host. This is a perfectly normal endeavor that has such a vast array of uses I would never be able to list them all.
I will, however, dive into some general use cases for those who are curious what they can do with proxies on their website, and then I’ll get into the four reasons these proxies might be failing.
Why Use Proxies with Your Website?
In general using proxies on your website will allow you a large degree of functionality for your readers or subscribers. Proxies make complicated, large-scale tasks happen in a flash, and fail less often, so it’s worth considering if you’re offering any service that’s traffic intensive.
Tools Powered with Proxies
A tool on your website could be a dedicated web scraper for a type of website, a geolocation program that allows users to identify information based on geography, a data conglomerator, or a rank checker.
Whatever the tool may be, it typically takes a lot of number crunching to make it work. In the example of a tool that scrapes the web behind the scenes, you’ll often need to pull in thousands of data points in a few seconds to retain your audience. Anything that takes longer will result in the person moving on.
First of all, you would need proxies to do the scraping regardless. You won’t want Google to connect your IP address with so many requests, as you would get flagged and banned in an instant.
The fact that the tool is public-facing means it needs to be accessed way more often, and you need it to work about 95% of the time. If not, nobody will think it’s reliable.
Therefore you need a ton of proxies (depending on your project size) and you need them to work flawlessly with your web host.
Coding It Up
The key to making these tools and other functions work with proxies is to code them correctly. You’ll have to code any application you have running to interact with the proxy first, before using a server’s IP address, so that the train doesn’t stop running.
To do this, and to troubleshoot the four issues below, make sure you have your coder hat on.
The 4 Reasons Your Proxies Aren’t Working
With the above in mind, there’s clearly something at stake when your proxies don’t work. It’s one thing if you can’t run reports for your own research, but if the client-side tools or operations fail, you’re going to hear about it. You might lose customers.
Keeping the proxies oiled and ready to go is the best bet, so knowing what is causing the problem in the first place is critical. The four reasons I list below are what is likely to be causing your problem. They aren’t the most technical or nitty gritty issues, but the ones you should always check before calling your technical service rep.
1. Double Check Your Authorization
There is proxy authorization, and then there’s web host authorization. In most cases both are needed for you to successfully run tools and other programs through a proxy, and if either is incorrect it will look like your proxies are broken.
Proxies are typically authorized by username and password, which is the most common way of authorization on the web. Most websites use it, and your web host probably uses it, too. For proxies, it just means you have to make sure the tool or program you’re running has to have the correct username and password combination when it tries to use proxies. You’ll have to code this in, and make sure to account for proxies from different providers.
There’s also proxy authorization by IP, in which all your proxies are automatically allowed if accessed by a certain IP address. Typically you can whitelist a couple addresses. However, this is not the best method for running tools, because your server IP address may change, and that’s the one needs to be whitelisted to work.
You won’t necessarily get a notification about this, and it could be why things aren’t working.
Web Host Authorization
Your web host and server has one unique login, almost always with a username and password combination. Depending on how your tool, script, or program (they’re all relatively the same here, and I’ll use script from now because it’s the actual code) runs, it may need to sign into the web host in order to present the data to your customers.
In this case you’ll need to have the correct server IP entered in the script, along with the correct username and password combination. While the latter you should have written down somewhere, the former (the server IP) can be difficult to find.
You can find your server IP address with PHP by typing — $_SERVER[‘SERVER_ADDR’] — into your script. If that’s too technical (or you’re using another language) navigate your web host to find the correct IP address.
Doing both of these at once, and ensuring the information in your script is up to date, will make sure your proxies are working on this level.
2. Check Firewall and Open Ports
The next major check is to make sure your server or web host does not have an active firewall up. This may sound obvious, but you’d be surprised. Typically web hosts are very concerned with security, and have a lot of measures in place to keep proxy connections and other random entries to your website out, rather than letting them all in.
You can always contact your web host to see if a firewall is running somewhere in your server (this is the most common issue).
The second part of this step is the open ports. Proxies can only connect to things when their ports are open — if they are closed, it will look like the proxy is not working. Double check all of your proxies (this may be time consuming) and manually open the ports you’re trying to connect on.
Likewise, if the proxies are connecting directly to your server IP, make sure that the correct port for that is open as well.
3. Make Sure cURL and Other Linux Dependancies are Enabled
cURL is is a Linux command, and in this troubleshoot step I’ll be talking about it and other linux dependencies (commands) that require you to fetch information. cURL and other dependencies can use proxies, but they don’t always have to. That’s not the important bit.
The important bit is that some web hosts and servers block cURL and these other Linux dependencies. Often they are blocked by default, so you’ll need to go in and enable them. Sometimes they are blocked at a higher level, and you’ll need to get in contact with your web host to troubleshoot the issue.
Likewise, there are other scripts and methods of information grabbing, like running a whois, that need to be installed in the fist place to run correctly. Some people forget that those don’t come pre-installed in a server, or forget to place them in the script specifically.
You’ll need to check the web host’s allowance of these, install them properly, and then correctly write the script to get it all working.
4. Double Check Your Code
This relates heavily to all of the above — if your proxies aren’t working and you’ve tried every other method, check your code. Check it again. It’s a lot of little lines and a single mistake could make or break a proxy connection, and therefore your entire tool or operation.
If you’re a hardcore coder you can do this yourself. Whether or not you want to, using a tool like Firebug to debug your code lines is always helpful, and will save time in the long run. In fact, it should be a standard practice to debug your code and run over it (just like I do with an article) to make sure it’s up to snuff.
If you’ve done this and can’t find the issue, but believe it’s in your code, you can always consult with a developer. If you’re running a website, managing tools, and trying to build a client base, you may not have the time or focus needed to sort through a long list of code. Let the developer sort it out — they’ll have fresh eyes with which to view it, might solve your problem quickly, and might even make it run a bit faster.
Those four steps are what you should run through every time your proxies stop working. Most of the time they will solve the issue, but they might not. It’s happened to all of us, and it’s not the end of the world. However, because you’re script is probably affecting clients, you will need to fix it quickly.
There are some final, obvious steps you can take.
First, contact the web host. Tell them what the issue is and what you’ve done to solve it. The problem may be on their end, and may be something you just can’t guess on your own. Hopefully they have great customer service and will be able to speak to you from a developer’s perspective, getting to the root of the problem immediately.
Second, contact your proxy provider. Actually, before contacting your provider, run the proxies through a basic test. See if they work for web browsing. Then contact your provider with the problem, what you’ve tried, and if the proxy works in other situations. There’s a chance the issue is with them, not you, and they will be able to fix it easily.
Those two are last step measures, but getting the professionals involved (and the people whose services you pay for) will usually solve the problem.
My last piece of advice: Write your scripts with the “if IP is blocked, try again with a new IP” mentality. This will ensure that even if one IP is failing for some reason, the rest of them will be tried before the tool shuts down. This way, you’ll know if the problem is widespread, or specific to a proxy or set of proxies.
Good luck, and remember to run tests frequently to mitigate issues before they arise.
The views, information and opinions expressed in this guest article are for educational purposes only and do not necessarily reflect the views and opinions of GhostProxies.
We do not promote illegal activities or distribute tools for such activities. All trademarks and images used in this article are property of their respective owners. Please contact us if you believe any content within this article is in any violation of law or copyright.