Go IPv6 Proxy

go-proxy6

I work with Go daily at AccessFintech, but I always wanted to create something using the pipeline design pattern specifically in Go. I learned about this pattern from Hands-On Software Engineering with Golang by Raymond Butcher - a goldmine for anyone diving into Golang and pipeline work.

This project came from a real need - I wanted a high-performance IPv6 proxy that would rotate through random IPv6 addresses from my subnet. I found http-proxy-ipv6-pool but it hadn’t been updated in 3 years and was written 100% in Rust without any Docker images. I needed something I could extend and improve if needed, so I built my own.

Plus, after my recent experience with IPv6 neglect across major platforms, I wanted to build something that was IPv6-first by design.

The final results exceeded my expectations. The proxy can handle 199,588 requests per second with only 5.9μs latency per request on my M2 MacBook. Pretty solid for Go!

Performance Numbers That Made Me Happy

Benchmark Results (Apple M2, Go 1.21):
├── Pipeline Throughput: 199,588 req/sec (5.9μs latency)  
├── IPv6 Generation: 4,161,603 ops/sec (282ns per address)
├── Target Resolution: 7,660,347 ops/sec (155ns per resolve)
├── Memory Efficiency: 792 B/op, 25 allocs/op
└── Resource Usage: 2 goroutines per pipeline

What is IPv6 Proxy?

For those unfamiliar with IPv6 - it’s the modern internet addressing system that gives you a lot more IP addresses to work with. Like, really a lot:

flowchart TD
    A[Your IPv6 Subnet /64] --> B[2^64 addresses available]
    B --> C[18,446,744,073,709,551,616 addresses]
    C --> D[That's 18 quintillion addresses!]
    
    E[IPv4 Internet] --> F[4.3 billion addresses total]
    F --> G[Already exhausted]
    
    style G fill:#ffcdd2

How IPv6 addressing works: Think of it like having your own city block where you can assign house numbers. The network prefix is your street, and you get to randomly assign any house number from 1 to 18 quintillion. That’s a lot of houses.

graph TB
    A[Network Prefix: 2001:db8::/64] 
    B[Your 64-bit subnet]
    C[Host bits: randomizable]
    D[Each request = new random IP]
    
    A --> |"Fixed part
Identifies your subnet"| B
    B --> C
    C --> |"18 quintillion possibilities"| D

Our proxy pipeline architecture: This is where Go’s concurrency shines. Three stages running in parallel, each optimized for speed. The IPv6 generator is basically just fancy random number generation, which is why it’s so fast.

graph LR
    E[HTTP Request] --> F[IPv6 Generator]
    F --> G[Target Processor]
    G --> H[Proxy Processor]
    H --> I[Response via Random IPv6]
    
    F -.->|"282ns per address"| F1[Random IP generation]
    G -.->|"155ns per resolve"| G1[Parse host:port]
    H -.->|"Actual network I/O"| H1[HTTP/HTTPS execution]
    
    F1 -.-> F
    G1 -.-> G
    H1 -.-> H

Security by design: No fallbacks, no “oops we used IPv4 by accident.” If it’s not IPv6, it doesn’t get through. Period. This isn’t a bug, it’s the entire point.

graph TB
    subgraph input ["Incoming Requests"]
        J[IPv4 Request]
        L[IPv6 Request]
    end
    
    subgraph processing ["Security Filter"]
        M{Protocol Check}
    end
    
    subgraph output ["Result"]
        K[❌ BLOCKED]
        N[✅ PROXIED]
    end
    
    J --> M
    L --> M
    M -->|"IPv4"| K
    M -->|"IPv6"| N
    
    style K fill:#ffcdd2
    style N fill:#c8e6c9

Bottom line, this proxy:

• Routes HTTP/HTTPS traffic through random IPv6 addresses from your 18 quintillion available addresses
• Blocks all IPv4 requests by design (no leakage, no fallbacks)
• Uses a high-performance pipeline architecture
• Generates new IPv6 addresses from your subnet for each request

It comes with Docker Compose for easy deployment. The Docker setup handles all the IPv6 routing automatically.

And for the extra mile, it’s designed to fail-fast if IPv6 isn’t available rather than falling back to IPv4.

How is it written?

The project was written in Go, because I wanted to focus on performance and concurrency. Go’s goroutines and channels made building the pipeline architecture really straightforward.

I also used structured logging with slog and proper benchmarking to make sure the performance claims were real, not just marketing.

The architecture uses a pipeline pattern with three stages:

• IPv6Generator: Creates random addresses (282ns per address)
• TargetProcessor: Resolves targets and protocols (155ns per resolve)
• ProxyProcessor: Handles the actual HTTP/HTTPS requests

What’s next?

For now, the proxy does exactly what I need it to do. I might add some monitoring endpoints or configuration hot-reloading, but the core functionality is solid. Always open to suggestions and PRs though!