Community Stoies: All I Wanted Was A Ride Home

By Paul Reinheimer

Years ago, I worked as a developer for a moderately sized company that built high traffic websites. Our systems were ad-hoc to the core. We “deployed” using sFTP to the primary server, then, through some secret sauce, our code was copied to all the other servers in the cluster. We used Subversion, but there was nothing to guarantee that the code you saw in the repo was actually running the websites. In fact, a classic debugging trick was to upload your code to some secondary server and try it out there, in production. I’m glad my days of checking www24.example.com for bugs are behind me.

My friend Nick worked in QA, testing our various websites. He conveniently had a car and lived near me. Like most people in QA departments, he was overworked and underappreciated. I remember swinging past his desk at the end of the day to discover he was working late again. For starters, our website used different credit card processors depending on where you were in the world. All of those conditions needed testing. To make his life a little easier, Nick had found a few “free web proxies” around the world. He would punch in the page he needed to test on those, then wait for them to present his page, injecting new ads all the while. This took hours. On Nick’s frequent late nights, I was left to take the subway home.

I talked the problem over with a few people, and it didn’t seem too difficult to solve. We could buy some virtual servers from hosting providers in a few locations, install a proxy server, and give Nick the credentials. So I did just that. The initial setup was laughably poor: inconsistent server setup, no credential management, not even a website. Just some proxy servers and some manually generated credentials.

But it worked.

With this new tool, Nick could test websites quicker, with confidence that the servers he was using were actually where they claimed to be, and avoid the problems that came with the ad-supported websites he’d been using previously. New bugs were found and fixed, and Nick’s employer became our first paying customer. Nick also stopped having to work late, so he could give me a lift home on chilly days.

An introduction to Location-Based Websites?

Some websites (including my former employer’s) use GeoIP to figure out where their users are located. It’s kind of like looking at the country code or area code for an incoming phone call to take an educated guess on its origin. In this case, the website looks up your IP address in a database (MaxMind is a popular provider) that turns the IP into a location. Some companies use GeoIP-based localization to optimize their website for users based on their location: showing prices in the right currency, displaying the correct shipping costs automatically, showing relevant products prominently, and so on. Others, like Netflix and Hulu, for example, use GeoIP-based locating to restrict content based on your location.

When you use a proxy server or VPN, the websites you visit see only the IP address of the proxy server, not your own. So when they run the IP address through a GeoIP database they get the location of the proxy server, not yours, and serve the website as they would for a user in that proxy server’s location.

Growing Pains

In the early days, our process was simple: whenever a new customer signed up we’d take the money they gave us and use that to pay for a server in a new location. That worked really well for the first twenty or so servers: London, Paris, Berlin, Tokyo, Seoul, Moscow, Sydney, New York, San Francisco… all easy places to find a hosting provider! 

As our customer base grew, however, and our customers started asking for locations outside of major tech hubs, we quickly realized that not all hosting providers are created equal, and some of them are only worth working with if you want to have hilarious/tragic stories and enjoy apologizing to customers.

As we worked with more hosting providers, we learned more about how we needed to select them. A fair number offered “unlimited bandwidth,” which sounded great, but none of them ever meant it. As soon as you showed up on their usage charts, they’d cancel your account and ignore your emails. Others would claim to be in a location we needed but were actually in Dallas or Germany. We’d discover this when our ping statistics showed that some server allegedly in Suriname thousands of miles away was 0.6 milliseconds away from our Dallas server (when it should have been more like 100 ms). 

We also eventually discovered that while I’d set up our systems to collect payment before users received an account, there was no code in place to deactivate them after their month was up. There was also nothing to remind them to pay again, so we went a solid year with a bunch of customers who had paid us exactly once. Our accountant got happier when we fixed that one :). 

Where Are We Now

What started as a weekend project to help my friend Nick test our websites so that he’d be able to give me a lift home has now been running for ten years and employs seven people around the world. The company has gone from a small handful of servers to 249 cities in 89 countries. 

We’ve learned a lot about maintaining a network of global proxy servers, growing our customer base, harnessing our network to build new products. And we’re now much more comfortable saying “where is your datacenter?” in Spanish. Nick is still a customer, although I moved on from that company years ago, and they are still using WonderProxy’s servers to make sure their websites are working as designed. 

We’re incredibly proud that this little side project, now called WonderProxy, has helped so many folks leave work promptly at 5 pm.

Author Bio

Paul Reinheimer is the president and co-founder of WonderProxy Inc. When he’s not seeking out new locations for proxy servers you can find him at home enjoying photography, baking, and playing with his children. You can find him on Twitter at @preinheimer, and his company tweets at @wonderproxy.