DEV Community: Akash Panchal

Configuring HTTP Proxy for gRPC in C# Without Environment Variables

Akash Panchal — Sat, 13 Dec 2025 12:50:48 +0000

The Challenge

You have a gRPC client in C# using Grpc.Core that needs to route traffic through an HTTP proxy. Sounds simple, right?

Not quite.

If you've searched for solutions, you've probably found:

Set http_proxy environment variable ✅ Works, but affects ALL HTTP traffic
Use Grpc.Net.Client with HttpClientHandler.Proxy ✅ Clean, but requires library migration
Set grpc.http_proxy channel option ❌ Doesn't work in Grpc.Core

I needed per-channel proxy configuration without affecting other traffic and without migrating libraries. So I dove into the gRPC C-core source code to understand how http_proxy actually works.

Source Code References (gRPC v1.10.0)

If you want to explore the internals yourself, here are the key files:

File	Purpose
`http_proxy.cc`	Reads `http_proxy` env var, sets channel args
`http_connect_handshaker.cc`	Sends HTTP CONNECT request to proxy
`secure_channel_create.cc`	SSL/TLS target name override handling
`channel.cc`	Default authority header logic
`ChannelOptions.cs`	C# channel option constants

What I Discovered

When gRPC honors the http_proxy environment variable, it doesn't do anything magical. It simply:

Parses the proxy URL
Sets internal channel arguments
Uses these arguments during connection

The key insight: these channel arguments are accessible via ChannelOption in C#!

The Solution

Understanding HTTP CONNECT Tunneling

HTTP proxies use the CONNECT method to create TCP tunnels:

┌────────┐         ┌───────┐         ┌────────────┐
│ Client │   TCP   │ Proxy │   TCP   │ gRPC Server│
└───┬────┘         └───┬───┘         └─────┬──────┘
    │                  │                   │
    │ TCP Connect      │                   │
    │─────────────────►│                   │
    │                  │                   │
    │ CONNECT host:port HTTP/1.1          │
    │─────────────────►│                   │
    │                  │                   │
    │                  │ TCP Connect       │
    │                  │──────────────────►│
    │                  │                   │
    │ HTTP/1.1 200 Connection established │
    │◄─────────────────│                   │
    │                  │                   │
    │◄──────────── TCP Tunnel ───────────►│
    │         (TLS + gRPC flows here)      │
    │                  │                   │

Once the tunnel is established, TLS handshake and gRPC communication flow through transparently.

The Three Magic Channel Options

private Channel CreateChannel(string targetEndpoint, SslCredentials credentials, string proxyEndpoint)
{
    string proxy = proxyEndpoint?.Trim();

    if (!string.IsNullOrEmpty(proxy))
    {
        // Extract hostname without port for SSL validation
        string targetHost = targetEndpoint.Contains(":") 
            ? targetEndpoint.Substring(0, targetEndpoint.LastIndexOf(':')) 
            : targetEndpoint;

        var options = new[]
        {
            // 1. HTTP CONNECT tunnel target (host:port)
            new ChannelOption("grpc.http_connect_server", targetEndpoint),

            // 2. SSL SNI + certificate validation (hostname only)
            new ChannelOption(ChannelOptions.SslTargetNameOverride, targetHost),

            // 3. HTTP/2 :authority header (host:port)
            new ChannelOption(ChannelOptions.DefaultAuthority, targetEndpoint)
        };

        // Channel connects to PROXY, tunnels to TARGET
        return new Channel(proxy, credentials, options);
    }

    // Direct connection
    return new Channel(targetEndpoint, credentials);
}

What Each Option Does

1. `grpc.http_connect_server`

Purpose: Tells gRPC where to tunnel

What happens: When gRPC connects to the channel target (the proxy), it sends:

CONNECT api.example.com:443 HTTP/1.1
Host: api.example.com:443

Format: host:port (port is required!)

2. `SslTargetNameOverride`

Purpose: SSL/TLS hostname for SNI and certificate validation

The problem: Without this, gRPC would:

Send SNI for the proxy hostname
Validate the certificate against the proxy hostname
Both are WRONG — we need the actual target's certificate!

What happens:

TLS ClientHello contains correct SNI: api.example.com
Certificate validation checks against: api.example.com

Format: hostname (NO port — SSL certificates don't include ports)

3. `DefaultAuthority`

Purpose: Sets the HTTP/2 :authority pseudo-header

The problem: gRPC servers use :authority for routing. Without this override, it would be set to the proxy address.

What happens:

:method: POST
:scheme: https
:authority: api.example.com:443  ← Correct!
:path: /mypackage.MyService/MyMethod

Format: host:port (port often required for server routing)

Complete Flow Diagram

┌─────────────────────────────────────────────────────────────────┐
│                        YOUR APPLICATION                          │
│  Channel target: proxy-server:8080                              │
│  Options:                                                        │
│    grpc.http_connect_server  = "api.example.com:443"            │
│    SslTargetNameOverride     = "api.example.com"                │
│    DefaultAuthority          = "api.example.com:443"            │
└──────────────────────────────┬──────────────────────────────────┘
                               │
          Step 1: TCP Connect  │
                               ▼
┌─────────────────────────────────────────────────────────────────┐
│                        HTTP PROXY                                │
│  Receives: CONNECT api.example.com:443 HTTP/1.1                 │
│  Action:   Opens TCP connection to api.example.com:443          │
│  Returns:  HTTP/1.1 200 Connection established                  │
└──────────────────────────────┬──────────────────────────────────┘
                               │
          Step 2: TCP Tunnel   │ (transparent passthrough)
                               ▼
┌─────────────────────────────────────────────────────────────────┐
│                     TLS HANDSHAKE                                │
│  ClientHello SNI: "api.example.com"    (SslTargetNameOverride)  │
│  Server sends certificate for: "api.example.com"                │
│  Client validates cert against: "api.example.com" ✓             │
│  [mTLS: Client certificate sent if configured]                  │
└──────────────────────────────┬──────────────────────────────────┘
                               │
          Step 3: Encrypted    │
                               ▼
┌─────────────────────────────────────────────────────────────────┐
│                      gRPC SERVER                                 │
│  Receives HTTP/2 request:                                       │
│    :authority = "api.example.com:443"    (DefaultAuthority)     │
│    :path = /mypackage.MyService/MyMethod                        │
│  Routes and processes request ✓                                 │
└─────────────────────────────────────────────────────────────────┘

Why Not Just Use Environment Variables?

Approach	Scope	Risk
`http_proxy` env var	Global (all HTTP)	May break other services
Channel Options	Per-channel	Isolated, controlled

Environment variables are global. If your application makes HTTP calls to multiple services, and only ONE needs proxying, you can't use environment variables safely.

Channel options give you surgical precision.

By understanding how gRPC handles proxies internally, we can configure per-channel proxy support without environment variables, keeping our other HTTP traffic unaffected.

Have you faced similar challenges with gRPC proxying? Drop a comment below!

Bootstrap a saas in a month, Here is How I did it

Akash Panchal — Wed, 25 Oct 2023 00:21:36 +0000

How I bootstrapped a micro SaaS using Amazon’s Leadership Principles

Two months ago, I made the decision to leave my software engineering role at Amazon and pursue my goal of building a bootstrapped SaaS startup. The idea was for a text summarization tool that could condense content while maintaining key context — something I knew I would use constantly as an avid online reader.

With only personal savings backing me, I needed to build and validate an MVP quickly and efficiently. Luckily, my (almost) 2 years at Amazon ingrained leadership principles that would prove invaluable as a scrappy solo founder.

Here is a detailed look at that journey building LessenText — a text summarization tool for efficiently condensing content — as a solo, technical founder.

Step 1: Validating Demand (Months 1–2)

Sure there were existing summarization tools, but they lacked the control and customization I wanted. I started envisioning a SaaS focused specifically on summarizing longer written content while preserving key context. And allowing users to easily adjust and refine the generated text themselves.

One could argue that, chatGPT can help for free. But this time around I’m solving the UX problem not the Technical problem.

Thus, before investing significant time, I built a simple landing page using yep.so to validate interest. Over 3–4 months I drove 100 beta signups with minimal promotion. My goal was to gauge interest and collect emails from potential customers.

https://yep.so/p/lessentextai

Seeing that initial demand gave me conviction there was a need I could fill better than competitors.

Step 2: Designing an Intuitive User Experience (Weeks 1–2)

With demand validated, I focused on UX and UI design. As an ex-Amazonian, the Customer Obsession principle was ingrained in me. So I wanted to craft an intuitive, seamless experience for generating summaries.

I explored products like ChatGPT to understand current limitations and pain points. Two big gaps were lack of summarization controls and exclusive features focusing text summarization.

Keeping these user-centric insights top of mind, I sketched out user flows and wireframes. I wanted clean, intuitive interfaces that solved those key issues.

I also started learning NextJS during this design phase to prepare for rapidly building my vision as prototype code.

Step 3: Developing the MVP Version (Weeks 3–6)

https://productschool.com/resources/glossary/mvp-minimum-viable-product

POC(proof of concept) vs MVP(minimum viable product)

I really believe that a POC should focus on core proposition but an MVP should be close to the real product.

See the POC at, https://alpha.lessentext.com/ . This POC really helped me brainstorm the ideas and features (with myself 😋)

What I wanted to focus on is creating an MVP version which can be a whole product and the features can be developed on the top of it, without starting from the scratch.

MVP(minimum viable product)

With design direction set, it was time to build. I set an ambitious goal of getting a functioning MVP online in 6 weeks. To achieve that timeline as a non-technical solo founder, I heavily leveraged some of the core Amazon leadership principles ingrained in me.

I’ve also came up with 1-pager memo like Amazonins do.

1. Customer Obsession kept me focused on solving real user problems like lack of summarization controls and reading/savings features. I refused to get distracted by non-essential features.

2. Dive Deep enabled me to ramp up with frontend technologies. I had previously worked in Web development during PHP and jQuery era.

I brushed Javascript, learned enough ReactJS and NextJS by studying obsessively and testing code examples, I gained enough skills to build my UI mockups.

3. Ownership meant wearing many hats as a one-person team — not just coding, but also researching, testing, infrastructure setup and more. My experience at Amazon running projects end-to-end gave me confidence I could handle this variety.

Good to know: there are no devops team at Amazon. Engineering teams are responsible for setting and monitoring their own infra.

I often had to study and iterate pricing strategy by calculating usage cost and customer pricing. It was overwhelming for me at first but I’m satisfied with the outcome and the learnings. It’s an ongoing process for any business whether be a large or small.

4. Frugality led me to use free tiers from tools like Vercel, PlanetScale, and Railway while in beta mode. I wanted to prove product-market fit before incurring greater costs.

The 6 week sprint was grueling, with many late nights spent coding. But seeing my vision turn into a real product was tremendously exciting. In the end, I was able to launch an initial version of LessenText to a small waitlist right on schedule.

Step 4: Gathering Feedback from Early Users (Week 7+)

With a functioning beta product released, my goal shifted to learning. I wanted to gather feedback from early adopters to guide improvements before wider rollout.

https://lessentext.com

I also took help from a friend and family guy to try out And got some hidden bugs and interesting perspective from them.

Ongoing refinement based on real usage, monitoring churn metrics, and engaging with customers will be crucial. Thanks to lessons from Amazon, ignoring user feedback is never an option for me.

Now, If you’ve come this far, please try out https://lessentext.com free tier. And if you’re a student or a researcher, please connect me at contact@lessentext.com to get a minimal profit discount.

Continuing the Journey

Reaching an initial launch was a major milestone. But building a successful bootstrapped SaaS that customers love is a never-ending journey.

The core Amazon leadership principles that enabled me to ship an MVP fast remain just as relevant today. I’m still customer obsessed, diving deep on technical topics, and reluctant to overspend.

But I’ve also learned how challenging it is working alone for long periods. Staying motivated with no team for support or alignment is draining.

Resources helped me during my journey

Technical learnings (Javascript, ReactJS, NextJS, Building AI saas)
Free infra resources (Vercel, Planetscale, Clerk, Highlight, Railway)
Pricing Strategy — paddle blog (https://www.paddle.com/blog)