Ein Baum und seine Abenteuer

Go based proxies for developing mobile websites on corporate WiFis

You might know this scenario:

We would really love to debug the web-app on an actual phone but they way our corporations WiFi is set up just won't allow it…

When networks become a show stopped for development.
When networks become a show stopped for development.

If you do, stay tuned because in this blog post we will examine how we as developers can handle tightly secured WiFi Networks and still get all the connectivity we need.

We will set out by exploring a detailed, real world scenario and then explore a solution using hotspots and Go based proxies.

An exemplary situation

Recently we were developing a Capacitor based hybrid web application. To really debug that you run a webserver on your laptop and connect your phone via WiFi. Only trouble: on our corporations WiFi phones get isolated for security reasons.

Phones get isolated for security reasons!

Luckily the isolation problem can quite easily be solved by connecting your laptop with the internet via ethernet and using the Laptops WiFi to opening up a hotspot. Just make sure to secure that with a strong password!

Sadly, that cut our laptops off from the internal networks which we had to reach again by connecting our laptops to the companies VPN (jup, ethernet only went to the public internet). While the hotspot handed the internet connection through to the phone it doesn't do the same magic for the VPN connection. So, how do we now get this connection through to our phones?

We need the internal network because the phone needs to connect to the deployed test backend, available on the companies internal network that our laptops connect to using VPN.

Muscle emoji
Muscle emoji

Proxies to the rescue

Handing traffic around on a network is something we as web developers are familiar with. Often time you need an NGINX to hand requests from an entry URL to the right internal service running on a different machine (or to dockerize a web app). That is called a proxy.

As just mentioned we could setup an NGINX or similar on our laptops and use that as a proxy. And this does work. However it makes it more difficult to check the solution into version control. A better maintainable version is to write a simple proxy in your language of choice. We choose Go.

package main

import (

func main() {
    proxy := goproxy.NewProxyHttpServer()
    proxy.Verbose = true
    log.Fatal(http.ListenAndServe(":9090", proxy))

That is all the code you need to now run go run proxy.go and start a proxy on your machine.

Green light for our traffic thanks to proxies.
Green light for our traffic thanks to proxies.

On your phone you now need to tell it to not only connect to your laptops hotspot but also use a proxy. For that you likely need your laptops IP within the hotspot (it will likely always assign itself the same one) as well as the port (here: 9090) to set that up.

With this you are now ready to finally do development on your phone.


Today we looked at how a simple proxy in Go can help us to develop in tightly secured corporate networks. With just a few lines of code and a bit of setup you can get going.

Now, go out and build something awesome ✨


There is one obvious question here: Is this a good idea??!?

I am so glad that you asked. And in truth I am not sure. It surely feels like a hack and it is one. We are basically getting around a security measurement established for a good reason. I would encourage you to see the practices here as a short term solution and to pick up a discussion with you management and IT about a long term solution.

Any comments and ideas for better solutions are highly welcome and appreciated.



I am a JavaScript Enthusiast and developer for the fun of it!
Here I write about webdev, technology, personal thoughts and anything I finds interesting.

More about me

Read next

Dockerizing modern web apps

These days everything is shipped in containers, even software.
These days everything is shipped in containers, even software.

Most websites these days are Single Page Applications (SPA for short) where a single entry file handles all routes that a user might visit. Swept up in the ongoing trend of hosting in the cloud you might find yourself needing to “dockerize” your SPA. That is to say wrap it inside a Docker image and run it as a container.

Trying my hands at Deno v1.0

Denos awesome Dinosaur logo.
Denos awesome Dinosaur logo.

Following the release of Deno v1.0 I got excited to try my hands at it. These are my first experiences writing a simple tool in Deno.

A super fast introduction to Deno: Deno is the spiritual successor of Node trying to fix design mistakes that were made early on but recognized only late into the project. Deno supports TypeScript out of the box and relies on web-standards. In Deno you can import ES modules from any URL and use fetch like you would in the browser. To help unify the community on processes and workflows Deno provides a wide array of stdLibs and has build in solutions for bundling, testing and code formatting. You can read more in the Deno v1 release post.

Generative AI is here to stay!

"A path into the AI future" - generated using Midjourney
"A path into the AI future" - generated using Midjourney

Some reflections on what 2022 showed us about the future.

Generative AI describes AI that takes a prompt and generates something from it. Prime examples include Copilot which takes code or comments as a prompt to complete the code I want to write, ChatGPT which takes a chat message and replies with a human-like answer and Stable-Diffusion (or Dall-E, or Midjourney) which takes a prompt and returns a fitting image. All of these AIs made massive progress in 2022!