DEV Community: Arvin Khezri

Why Some Developer Tools Ignore Your Proxy Settings on Windows

Arvin Khezri — Tue, 06 Oct 2026 12:34:52 +0000

You enable a proxy on Windows.

Chrome works.

Edge works.

Then you run:

git clone https://github.com/example/project.git

and it fails.

You try:

npm install

Same problem.

Docker behaves differently.

WSL seems to have its own opinion entirely.

At this point, many developers assume the proxy itself is broken.

Often, it isn't.

The real problem is that developer tools do not all use Windows networking in the same way.

Some respect the Windows System Proxy.

Some use environment variables.

Some require their own proxy configuration.

Some run inside a separate networking layer.

And some bypass proxy settings completely.

Once you understand that, proxy troubleshooting becomes much easier.

The Wrong Mental Model

A common assumption is:

Enable proxy in Windows
        ↓
Everything uses proxy

But the real network path is closer to this:

Application
    ↓
How does this app handle networking?
    ├── Windows System Proxy
    ├── Application Proxy
    ├── Environment Variables
    ├── Direct Socket
    ├── Container Network
    └── Virtual Network Interface

That difference explains why one application may work while another does not.

1. Browsers Usually Follow Windows System Proxy

Browsers are usually the easiest case.

If you configure a local proxy using tools such as V2Ray or v2rayN and enable Windows System Proxy, browsers such as Chrome and Edge generally follow that setting.

The traffic flow looks roughly like this:

Browser
   ↓
Windows System Proxy
   ↓
Local Proxy
   ↓
Remote Server
   ↓
Internet

This is why testing a website in Chrome often succeeds immediately.

But that test only proves one thing:

Chrome can reach the internet through the proxy.

It does not prove that Git, npm, Docker, Python, or another application is using the same route.

2. Git Has Its Own Proxy Configuration

Git is a good example of application-level proxy behavior.

If Git does not automatically use your system proxy, you can configure it directly:

git config --global http.proxy http://127.0.0.1:10809
git config --global https.proxy http://127.0.0.1:10809

To inspect the current configuration:

git config --global --get http.proxy
git config --global --get https.proxy

And to remove it later:

git config --global --unset http.proxy
git config --global --unset https.proxy

The important lesson is not the command itself.

The lesson is that Git has its own networking configuration.

You should troubleshoot Git as Git, not assume the Windows proxy setting controls everything.

3. Environment Variables Are Common in Developer Tools

Many command-line tools support proxy environment variables.

For example:

HTTP_PROXY=http://127.0.0.1:10809
HTTPS_PROXY=http://127.0.0.1:10809

or:

ALL_PROXY=socks5://127.0.0.1:10808

Different tools support different variables.

On Windows PowerShell, you might temporarily set them like this:

$env:HTTP_PROXY="http://127.0.0.1:10809"
$env:HTTPS_PROXY="http://127.0.0.1:10809"

Then run your command:

npm install

This approach is useful because it lets you test whether the problem is related to proxy discovery.

If the command works after setting the environment variable, the remote server was probably never the real issue.

The application simply did not know which proxy to use.

4. npm and Package Managers May Behave Differently

Package managers are another common source of confusion.

A browser may load npmjs.com perfectly while:

npm install

fails.

npm supports its own proxy settings:

npm config set proxy http://127.0.0.1:10809
npm config set https-proxy http://127.0.0.1:10809

You can inspect them with:

npm config get proxy
npm config get https-proxy

The same principle applies to other package managers.

Composer, pip, pnpm, yarn, Maven, Gradle, and other tools may each have their own behavior.

This is why "the internet works in my browser" is not enough information when debugging developer networking problems.

5. Docker Changes the Networking Context

Docker makes things more interesting.

Imagine this setup:

Windows Host
   ↓
System Proxy

Your browser uses the proxy successfully.

Then you run:

docker build .

Inside the container, networking happens in a different context.

Now the architecture looks closer to:

Windows
   ↓
Docker Engine
   ↓
Container Network
   ↓
Application

The container does not automatically inherit every Windows proxy configuration.

You may need to pass proxy variables explicitly.

For example:

docker run \
  -e HTTP_PROXY=http://host.docker.internal:10809 \
  -e HTTPS_PROXY=http://host.docker.internal:10809 \
  my-image

Whether this exact setup works depends on your Docker configuration, but the architectural point remains the same:

A container is not just another Windows application.

It has its own networking layer.

6. WSL Is Another Network Environment

WSL creates another common misunderstanding.

You configure a proxy on Windows.

Then inside Ubuntu on WSL:

curl https://example.com

fails.

Again, this does not necessarily mean the proxy is unavailable.

Your Linux environment is not guaranteed to treat 127.0.0.1 exactly the way you expect relative to the Windows host.

You should think about the architecture explicitly:

Windows
   ↓
WSL Virtual Environment
   ↓
Linux Networking
   ↓
Application

You may need to expose or reference the proxy differently depending on your WSL setup.

This is why networking issues involving WSL can become confusing quickly.

7. Some Apps Ignore System Proxy Completely

Not every program uses Windows System Proxy.

An application can simply open its own socket connection.

Conceptually:

Application
   ↓
Socket
   ↓
Network Interface
   ↓
Internet

No system proxy is involved.

This behavior appears in:

custom desktop applications
game launchers
background services
networking tools
some developer software
UDP-heavy applications

In these cases, changing your Windows proxy settings may do nothing.

That is where network-level routing becomes relevant.

8. When System Proxy Is Not Enough

If only one tool fails, I usually configure that tool directly.

For example:

Chrome     → Windows System Proxy
Git        → Git Proxy
npm        → npm Proxy

That keeps the setup explicit.

But when many applications bypass the proxy, configuring each one manually becomes annoying.

This is where TUN-based routing can be useful.

Instead of asking each application to use a proxy, traffic can be intercepted at a lower networking layer.

The architecture becomes:

Applications
    ↓
Virtual Network Interface
    ↓
Routing Rules
    ↓
Proxy Core
    ↓
Internet

This is one reason tools such as V2Ray and Xray provide TUN-style networking options.

System Proxy vs TUN for Developers

For development machines, I think of the choice like this.

Use System Proxy When

browsers are your main concern
your tools support proxy configuration
you want a simple setup
you want easier debugging
you do not need to capture all traffic

Use TUN When

several apps ignore proxy settings
you need system-level routing
you use tools without proxy support
you need broader traffic interception

For normal Windows usage, a conventional VPN for Windows can also be simpler than managing application-specific proxy behavior manually.

The right choice depends on whether you want application-level control or network-level routing.

A Better Debugging Workflow

When a developer tool cannot access the internet through your proxy, don't immediately switch servers.

Use a predictable process.

Step 1: Verify the Proxy Itself

Test through a browser.

If the browser also fails, fix the base connection first.

Step 2: Check Whether the Application Supports a Proxy

Look for:

Application settings
Environment variables
CLI flags
Config files

Step 3: Compare Public IPs

Test from different environments:

Browser
PowerShell
WSL
Docker
Application

If they return different public IP addresses, they are using different network paths.

Step 4: Configure the Application Directly

If the application supports its own proxy, start there.

This is usually easier to debug than changing the entire machine's networking behavior.

Step 5: Move to Network-Level Routing Only When Needed

If multiple applications still bypass the proxy, consider TUN or a full-device VPN.

Why This Matters More in Restricted Networks

In a normal network environment, small differences between applications may go unnoticed.

In restricted or unstable networks, those differences become much more visible.

One application may connect successfully while another:

times out
gets reset
resolves DNS differently
uses another route
cannot reach a remote package registry

This is why network architecture matters so much for developers working with external APIs, Git repositories, package registries, and cloud infrastructure.

A reliable service such as ZiNet VPN can simplify the networking layer for users who do not want to manage proxy behavior individually.

And the same issue exists across devices.

A Windows workstation and an iPhone do not handle proxy and VPN traffic identically, so a separate VPN for iPhone setup is usually more appropriate than trying to reproduce a desktop proxy architecture on mobile.

The Key Idea: Debug the Network Path

When an application fails, don't just ask:

"Does the proxy work?"

Ask:

"Which network path is this application using?"

That path may be:

Application
   ↓
System Proxy

or:

Application
   ↓
Environment Variable
   ↓
Proxy

or:

Application
   ↓
Container Network
   ↓
Direct Internet

or:

Application
   ↓
TUN Interface
   ↓
Routing
   ↓
Proxy

Once you identify the path, the error becomes much easier to understand.

Final Thoughts

The biggest mistake I made when troubleshooting developer networking was assuming that Windows proxy settings applied equally to every tool.

They do not.

Browsers, Git, npm, Docker, WSL, IDEs, and custom applications may all use different networking mechanisms.

The practical rule is simple:

Start simple
   ↓
Identify the application's network path
   ↓
Configure the app directly when possible
   ↓
Use TUN or full-device routing only when necessary

Once you stop treating "proxy" as a single global switch and start thinking in terms of networking layers, debugging becomes much more predictable.

Why VPN Stability Matters More Than Speed: A Practical Guide for Users in Restricted Networks

Arvin Khezri — Tue, 14 Jul 2026 11:19:15 +0000

Many people choose a VPN based on one simple question:

"How fast is it?"

But after working with networking problems and internet reliability issues, I realized that speed is only one part of the experience.

A VPN with high speed but unstable connections can be much more frustrating than a slightly slower VPN that stays connected.

For users in regions with network restrictions or unstable internet conditions, reliability is often the most important factor.

Speed Is Not Everything

VPN performance depends on several factors:

Server location
Network congestion
VPN protocol
Internet provider routing
Server capacity
Connection stability

A speed test only shows one moment in time.

A stable connection shows the real quality of a VPN service.

Why VPN Connections Fail

There are several common reasons:

1. Network Restrictions

Some networks actively interfere with VPN traffic.

Different VPN protocols behave differently under these conditions, which is why protocol flexibility is important.

2. Overloaded Servers

Cheap or free VPN services often put many users on the same servers.

The result:

slower speeds
unstable connections
frequent reconnects

3. Poor Infrastructure

A VPN service is not only an application.

Behind every VPN is an infrastructure:

servers
routing
monitoring
security configuration
maintenance

Good infrastructure is what creates a reliable experience.

What Makes a Better VPN Experience?

When evaluating a VPN, I usually look at these factors:

Multiple Protocol Support

Modern VPN protocols can provide better performance and reliability depending on network conditions.

Good Server Distribution

More server locations usually mean better chances of finding a stable route.

Reliable Applications

A good VPN client should handle:

automatic reconnection
DNS protection
network changes
background connection management

Privacy Practices

A VPN changes who you trust with your network traffic.

A responsible provider should be transparent about:

data collection
logging policies
security practices

Choosing a VPN for Restricted Networks

For users in restricted environments, the priority order should usually be:

Connection stability
Compatibility with local networks
Privacy features
Speed
Price

A fast VPN that disconnects every few minutes is not a good solution.

Final Thoughts

The best VPN is not always the one with the highest advertised speed.

A good VPN is the one that provides a consistent, secure, and reliable connection when you actually need it.

For users who need a VPN connection designed for challenging network conditions, services like Zinet VPN focus on providing stable access and simple setup across different devices.

You can learn more about VPN setup and connection options here:

https://ipsabet.org

What factors matter most to you when choosing a VPN: speed, stability, privacy, or price?

I Stopped Treating WordPress Like a CMS (And My Projects Improved)

Arvin Khezri — Mon, 13 Jul 2026 13:01:45 +0000

For years, I built WordPress websites the traditional way.

Install a theme.
Add a few plugins.
Customize where needed.

It worked... until the projects became products.

Once I started building larger WordPress applications, I realized the biggest limitation wasn't WordPress—it was the way I was thinking about it.

WordPress Is More Than a CMS

Today, WordPress powers much more than blogs.

I've used it to build:

SaaS dashboards
Customer portals
WooCommerce applications
Internal business tools
REST API backends
Headless applications

In these projects, WordPress isn't just managing content.

It's acting as an application framework.

Plugins Aren't Always the Answer

One lesson I learned the hard way is that installing another plugin isn't always the fastest solution.

Every new plugin introduces:

more code
more updates
more dependencies
more potential conflicts

When a feature is specific to the product, I often prefer building it myself.

Smaller codebases are usually easier to maintain than collections of general-purpose plugins.

Think in Features, Not Pages

Instead of asking:

"Which page should I build next?"

I now ask:

"Which business feature am I building?"

That small change completely altered how I organize projects.

Each feature has its own:

business logic
API
validation
UI
permissions

The result is a cleaner and more maintainable architecture.

Performance Starts on Day One

Performance isn't something I optimize before launch.

It's part of every architectural decision.

Questions I constantly ask myself include:

Can this query be cached?
Do I really need this plugin?
Should this process run in the background?
Can this API response be reused?

Small decisions accumulate into significant performance gains.

AI Has Changed Planning More Than Coding

Like many developers, I use AI daily.

Surprisingly, I don't rely on it most for generating code.

Instead, I use it to:

review architecture
identify edge cases
challenge implementation decisions
improve documentation
brainstorm better solutions

The quality of my decisions has improved more than the speed of my typing.

Final Thoughts

The biggest improvement in my WordPress projects didn't come from a new framework or a new technology.

It came from changing my mindset.

When I stopped treating WordPress as "just a CMS" and started treating it as a platform for building products, my architecture became cleaner, my code became easier to maintain, and shipping new features became much more predictable.

How has your approach to WordPress changed over the years?

How Claude Changed the Way I Build WordPress Products

Arvin Khezri — Sat, 11 Jul 2026 17:28:20 +0000

Over the past year, AI has become a regular part of my development workflow. Like many developers, I initially used it to generate snippets or explain unfamiliar code.

That didn't last long.

Today, I use Claude as a development partner rather than a code generator. The biggest improvement hasn't been writing code faster—it's making better architectural decisions before writing code at all.

From "Write This Function" to "Design This Feature"

Instead of asking AI to generate a PHP function, I now start with higher-level questions:

How should this feature be structured?
What responsibilities belong in each class?
Which parts should be reusable?
What are the edge cases?
How will this affect performance and future maintenance?

This shift has reduced the amount of code I rewrite later.

Breaking Large Features into Smaller Systems

When building a WordPress product, it's easy for features to grow into large, tightly coupled components.

Now I describe the entire feature to Claude and ask it to divide the implementation into logical modules.

For example, instead of building a complete page builder as one feature, I separate it into:

Data layer
Rendering engine
UI components
API layer
State management
Validation
Settings

Working module by module keeps the project easier to maintain.

AI Is Surprisingly Good at Code Reviews

One workflow that has saved me a lot of time is asking Claude to review code I've already written.

Rather than asking "Is this correct?", I ask questions like:

What would become difficult to maintain six months from now?
Is this introducing unnecessary complexity?
Are there hidden performance issues?
Would another developer understand this structure?

The feedback is often more valuable than the generated code itself.

Documentation Becomes Easier

Writing documentation is rarely a developer's favorite task.

After implementing a feature, I ask Claude to generate:

technical documentation
README files
developer notes
API documentation
release notes

I still review everything, but starting from a solid draft is much faster than writing from scratch.

AI Doesn't Replace Experience

The more WordPress experience I gained, the more useful AI became.

That's because I stopped expecting perfect code and started using it to challenge my own decisions.

AI can generate code quickly.

It cannot understand your product, your users, or your business goals unless you provide that context.

My Current Workflow

Today, a typical feature looks something like this:

Define the product requirements.
Discuss architecture with Claude.
Break the work into smaller tasks.
Implement the feature.
Review the implementation with AI.
Refactor where necessary.
Write documentation.
Ship.

This process hasn't eliminated debugging or difficult decisions, but it has significantly improved the speed and quality of product development.

I'm curious how other WordPress developers are using AI today.

Has AI changed your workflow beyond simple code generation?