Self-Hosted vs. Commercial VPN: A Real Migration Review After LetsVPN Was Discontinued

1. Why Write This Article Specifically

Previously, I wrote an article titled “Full Process Review from LetsVPN Discontinuation to Self-built WireGuard VPN (With Pitfall Avoidance Guide)“.

That article was more of an “emergency record after a sudden incident”: the commercial VPN suddenly became unavailable, and I documented how I hit dead ends with alternative solutions, eventually purchased a VPS, set up my own WireGuard VPN, and got it running step by step.

But after several months of continued tinkering, I realized that this issue is actually not that simple.

At first, I thought the problem was:

Commercial VPNs are unstable, so I need a self-built VPN.

Later, I gradually realized that a more accurate statement would be:

Commercial VPNs and self-built VPNs are not simply a matter of “which is better,” but rather two completely different usage models.

Commercial VPNs solve for “out-of-the-box usability” and “hassle-free experience”;
self-built VPNs solve for “controllability” and “adjustability”.

The former is suitable for those who do not want to tinker, while the latter is for those willing to bear the costs of deployment, troubleshooting, and maintenance themselves.

This article is not a commercial VPN ranking, nor is it a recommendation for a specific VPS provider. It is simply based on my own real experience, reviewing why I gradually moved from commercial VPNs like Lantern and LetsVPN to a self-built solution using WireGuard, Wstunnel, Clash Verge Rev, and FlClash.

It should be noted upfront: this article only discusses personal technical learning, remote work, network connectivity, and experiences with self-built network environments. Different regions, platforms, and services have their own legal compliance requirements and terms of service. In actual use, you should comply with local laws and regulations as well as the relevant platform rules.

2. Why I Originally Used Commercial VPNs

Earlier on, I used Lantern, and I also used LetsVPN (formerly QuickConnect).

My needs at that time were actually quite simple:

• Being able to access overseas technical resources;
• Being able to use certain developer tools;
• Maintaining basic network connectivity;
• Not wanting to spend too much time on network configuration.

From this perspective, the advantages of commercial VPNs are very obvious.

They do not require you to purchase a VPS, configure a Linux server, understand WireGuard, iptables, DNS, or Clash rules, or worry about systemd auto-start. You only need to install the client, log in to your account, select a node, and click connect.

For most ordinary users, this is the ideal solution.

Especially in the beginning, I did not want to study “network architecture”. I just wanted a tool that could solve my access problems.

Therefore, the value of commercial VPNs does not disappear. Their greatest value is:

Hiding complex network configurations behind a productized interface.

This is also why many people prioritize commercial VPNs over self-built ones.

3. The First Problem with Commercial VPNs: Limited Number of Connectable Devices per Account

What really made me rethink commercial VPNs was not that they became completely unusable, but that they have many practical limitations.

When I was using LetsVPN, I encountered a very specific problem:

The number of devices that can be connected simultaneously to a single account is limited.

At the time, I had a Platinum membership, but I could still only connect up to 2 devices simultaneously.

For current usage scenarios, this limitation is quite noticeable: one phone and one computer already max it out. If you want to add a tablet, a backup phone, a Windows PC, or an Ubuntu machine, it becomes very troublesome.

Moreover, I did not find a simple way to “increase the number of simultaneous device connections by upgrading my account”.

This is not just my personal feeling. LetsVPN once mentioned in an official blog post that many users were dissatisfied with the “two-device limit” and hoped one account could support a third device; however, due to reasons such as the account system, membership management, network operation and maintenance costs, and countering network blocking, a multi-device sharing feature was not easily introduced.

This made me realize that although commercial VPNs are hassle-free, the account, number of devices, and subscription rules are all decided by the provider. Users do not have much agency.

If you only have one phone and one computer, this might not be a big issue.
But if you have multiple devices, or if you use Windows, Ubuntu, and Android simultaneously like I do, then the device limit becomes a very practical problem.

4. The Second Problem with Commercial VPNs: Subscription Tiers, Speed/Flow Limits, and Upgrade Costs

Another common issue is subscription tiering.

Many commercial VPNs or proxy services differentiate subscriptions based on:

• Number of connectable devices;
• Traffic quota;
• Speed tier;
• Node quality;
• Available regions;
• Peak hour stability;
• Customer and after-sales support.

This is not surprising in itself, because providers have to bear the costs of servers, lines, bandwidth, R&D, and customer service. When explaining the delay in multi-device sharing, LetsVPN also mentioned that the cost of high-speed dedicated server lines is higher than that of shared lines, and these costs continue to rise.

But from the user’s perspective, the problem is:

The usability of a commercial VPN often depends on its subscription rules.

If your subscription tier is not high enough, you might not have enough device slots;
if you need faster speeds, you might need a higher membership tier;
if you need more nodes, you might also need to upgrade your subscription;
if you need to bypass traffic or speed limits, you might still have to keep paying.

Therefore, the cost of a commercial VPN is not just “how much per month”.

It also includes:

• Device quantity limits;
• Traffic and speed limits;
• Subscription upgrade costs;
• Changes in provider rules;
• Uncontrollable node quality;
• Uncontrollable peak hour experience.

This is also one of the reasons I increasingly leaned towards a self-built VPN later on.

It is not that a self-built VPN is necessarily cheaper, but rather that its cost structure is clearer:
I know exactly which server I bought, where the line is, what the configuration is, and I know roughly which layer I should start troubleshooting from when a problem occurs.

5. The Third Problem with Commercial VPNs: Services May Suddenly Exit a Region

The discontinuation of LetsVPN was the time I felt the risks of commercial VPNs most deeply.

According to LetsVPN’s subsequent official statement, LetsVPN could no longer continue to provide VPN services to users in mainland China, nor could it promise to provide stable and reliable VPN services in the mainland Chinese market. Another announcement also mentioned that even if standard operations resumed globally, it did not mean that the connection experience in every region would fully recover, and at that time, service availability in mainland China could still not be guaranteed.

I do not want to make a hasty judgment here about all the reasons for LetsVPN exiting mainland China.

A more cautious statement would be:

This incident at least shows that using commercial VPNs in mainland China is affected by multiple factors, including the provider’s own operations, the network blocking environment, the regulatory environment, payment channels, and service area strategies.

For ordinary users, the most practical issues are:

• The service suddenly becoming unavailable;
• Users can only wait for the official restoration;
• Or apply for a refund;
• Or look for alternative products;
• Or temporarily switch to a self-built solution.

This is the biggest uncertainty with commercial VPNs:

They are very hassle-free normally, but once the service is unavailable, users are often left passively waiting.

This is also the direct reason why I gradually moved to a self-built WireGuard VPN starting from the LetsVPN discontinuation.

I documented this process fairly comprehensively in the first phase of “Full Process Review from LetsVPN Discontinuation to Self-built WireGuard VPN (With Pitfall Avoidance Guide)“. That article records the process of “going from commercial VPN unavailability to getting a self-built WireGuard running”, while this article focuses more on looking back and summarizing: how exactly should one choose between commercial VPNs and self-built VPNs.

6. The Fourth Problem with Commercial VPNs: The Barrier to Purchasing Compliant Commercial VPNs in Mainland China is Getting Higher

Later, I also tried contacting some providers that offer VPN or cross-border network services to enterprises.

The result was that they required providing at least a sole proprietorship business license.

This made me realize that commercial VPNs or cross-border network services facing mainland China are not just a matter of “having the money to buy”, but also involve qualifications, intended use, compliance, and target audience.

Looking at public policy, the Ministry of Industry and Information Technology (MIIT) once mentioned in its “Notice on Cleaning up and Regulating the Internet Network Access Service Market” that without approval from the telecommunications competent department, entities may not establish or lease dedicated lines themselves, including virtual private networks (VPNs) and other channels, to conduct cross-border business activities; international dedicated lines leased to users by basic telecommunications enterprises must also be explicitly designated for internal office use only.

I am not a legal professional, nor am I providing a legal interpretation here. But from my personal practical experience, at least one realistic conclusion can be drawn:

The difficulty of purchasing personal commercial VPNs in mainland China is increasing; purchasing compliant cross-border network services for enterprises may require enterprise or sole proprietorship qualifications.

Therefore, for ordinary individual users, the problems with commercial VPNs are not just price and stability, but also include:

• Whether it can be purchased;
• Whether long-term renewal is possible;
• Whether it is open to individuals;
• Whether enterprise or sole proprietorship qualifications are required;
• Whether the service area will be suddenly adjusted;
• Whether payments and refunds are smooth.

When these factors stack up, the long-term availability of commercial VPNs becomes increasingly uncontrollable.

7. The Fifth Problem with Commercial VPNs: The Trust Boundary Has Not Disappeared

Commercial VPNs have another unavoidable issue: you have to trust the provider.

Many people understand VPNs as “privacy protection tools”, but this is only partially correct.

VPNs can indeed route your network connection to another network exit, and they can also provide some protection in untrusted local network environments. However, the EFF reminds us in its VPN usage guide that the role of VPNs is often exaggerated by advertising; a VPN shifts some of the information originally visible to the local network or ISP over to the VPN provider. In other words, when using a commercial VPN, the VPN provider itself can still potentially see your traffic information.

The EFF also explicitly warns that VPNs are not anonymity tools, that commercial VPN operators may see user traffic, and that they may be subject to the laws and law enforcement requests of the country in which they operate.

This does not mean commercial VPNs are inherently untrustworthy, but rather:

Using a commercial VPN essentially shifts the object of trust from the local network to the VPN provider.

If it is just for ordinary access needs, this might be acceptable.
But if you want to have more control, a self-built VPN becomes attractive.

Of course, a self-built VPN is not entirely free of trust issues either. You still have to trust the VPS provider, you still need to protect server security, and you still need to avoid misconfigurations.

It is just that compared to commercial VPNs, a self-built solution at least gives you control over more of the intermediate steps.

8. Phase One of a Self-Built VPN: WireGuard Runs, But That Doesn’t Equal Long-Term Stability

After LetsVPN was discontinued, I started trying to build my own WireGuard VPN.

WireGuard officially positions itself as a “simple, fast, modern VPN”, emphasizing its use of modern cryptographic design.

From a technical perspective, WireGuard is indeed very well-suited as a starting point for a self-built VPN:

• Relatively simple configuration;
• Good performance;
• Wide client support;
• Available solutions for Windows, Linux, Android, and iOS;
• Highly suitable for technical users to understand the basic structure of a VPN.

Initially, my approach was very direct:

• Purchase a VPS;
• Install WireGuard;
• Connect local devices;
• Use AllowedIPs to direct domestic traffic straight through and route foreign traffic through the VPN.

This solution worked.

But after it was running, problems started to appear:

• Sometimes the speed was not ideal;
• Sometimes ports were interfered with;
• Sometimes server and client configurations needed to be modified;
• Sometimes maintaining traffic splitting rules was troublesome;
• Sometimes the handshake was normal, but certain websites or apps were still unavailable.

A specific point must be made here:

These problems cannot simply be attributed to a specific VPS provider.

For example, when I first used Vultr as a WireGuard node, I encountered issues with speed, ports, and traffic splitting maintenance. But this does not mean “Vultr itself is unstable”.

More accurately, it was the result of:

The combined result of native WireGuard + standard VPS line + exposed UDP + early traffic splitting scheme + specific network environment.

This is what I slowly figured out later on.

Regarding early WireGuard configuration and traffic splitting, I wrote two records:

• “WireGuard VPN Configuration Optimization: Direct Connection for Domestic Websites, VPN for Foreign Traffic (Tested Effective)“
• “WireGuard Domestic Direct Connection + Foreign Tunnel Configuration Pitfalls and Perfect Solution (Tested Usable)“

These two articles are useful for understanding my earliest AllowedIPs traffic splitting ideas. But looking back now, they are more like “early scheme records” and are not my current most recommended long-term stable solution.

The stability of a self-built VPN cannot be judged solely by which provider the server is from. It depends on at least four layers:

1. Server line layer: VPS region, ISP line, return route quality, peak hour performance;
2. Protocol encapsulation layer: WireGuard, Wstunnel, 443/WSS, etc.;
3. Traffic splitting rule layer: AllowedIPs, Clash Verge Rev, FlClash, GEOSITE, DNS;
4. Client maintenance layer: Windows, Ubuntu, Android, systemd, auto-start, memory usage.

If any one of these layers is not handled well, the final experience will suffer.

9. Practical Issues with Native WireGuard: Ports, Lines, Traffic Splitting, and Maintenance Costs

After continuing to use it for a while, I gradually realized that getting native WireGuard running is one thing, but using it stably long-term is another.

I encountered several typical types of problems.

1. WireGuard Occasionally Unavailable, No Handshake, Port Interference

I documented this type of issue in “Full Review of WireGuard Self-Built VPN Occasional Unavailability: From Normal Use → Sudden No Handshake → Port Blocked → Port Change + Smart Traffic Splitting Complete Solution Process“.

The phenomenon at the time was: WireGuard, which had been working normally, suddenly failed to handshake. Later, by troubleshooting ports, firewalls, server configurations, and client configurations, I gradually located the problem.

This type of problem easily leads people to think that “a certain VPS is unstable”. But now I prefer to summarize it as:

Exposing native WireGuard UDP in a complex network environment can incur port maintenance costs.

2. Multi-Port Forwarding Can Mitigate the Problem, But It Is Not the Final Answer

I later wrote “Ultimate Minimalist Solution for Self-Built WireGuard to Solve Frequent Port Blocking (Beginner-Friendly and Reproducible)“.

The core idea of that article was to reduce the cost of frequently modifying the server-side WireGuard listening port through server-side multi-port forwarding.

The value of this solution lies in:

• Reduced server maintenance costs;
• The ability to prepare multiple backup ports in advance;
• Faster recovery after interference.

But it did not solve all the problems.

Because the client might still need to switch ports, traffic splitting still relied on early rules, and the overall anti-interference capability did not see a fundamental upgrade.

Therefore, this type of article is more suitable as an “optimization record for the native WireGuard phase”, rather than the current final solution.

3. A Normal Handshake Does Not Mean All Networks Are Normal

Later, I also encountered the problem of “WireGuard handshake is normal, but web pages won’t open or the experience is very poor”.

I documented this type of issue in “WireGuard Handshake Normal But Can’t Open Websites? Why CN2 GIA is Necessary, with DMIT Deployment & Out-of-Stock Alternatives“.

This article made me further realize:

Whether a VPN is usable depends not only on whether WireGuard has a handshake, but also on the server line, routing quality, DNS, ISP network environment, and the specific access target.

This is also why I later focused on DMIT, CN2 GIA, and optimized lines.

However, it must also be emphasized here: DMIT or CN2 GIA solves “line layer issues”, not protocol encapsulation layer issues. They do not solve the same layer of problems as Wstunnel or Clash traffic splitting.

10. Phase Two of a Self-Built VPN: I Began to Understand the True Meaning of “Controllability”

After continuing to tinker, I gradually moved from “knowing how to set up WireGuard” to “understanding self-built VPN architecture”.

Early on, I thought the focus of a self-built VPN was:

Finding a good server and installing WireGuard on it.

Later, I found that the real focus is:

How to separate and handle connection, encapsulation, traffic splitting, DNS, and client maintenance.

For example:

• WireGuard handles the point-to-point tunnel;
• Wstunnel handles encapsulating the underlying traffic via WebSocket / WSS;
• Clash Verge Rev or FlClash handles client-side rule-based traffic splitting;
• DNS rules determine whether Google Play, Gmail, and some websites work properly;
• systemd and client settings determine whether it can automatically recover after a reboot.

In subsequent practice, I started trying the structure of ZgoCloud + Wstunnel + WireGuard + Clash Verge Rev / FlClash.

The key record for this solution is “ZgoCloud + Wstunnel + WireGuard 4x Speed Boost, Clash Verge Rev Auto Traffic Splitting and 443 Port Anti-Blocking Practical Guide“.

But we must also avoid a misconception here:

It is not that ZgoCloud is naturally more stable than other VPS providers, but rather that I adopted a more complete architecture at this stage.

The stability improvement mainly comes from the combination:

• Wstunnel + 443/WSS encapsulation;
• WireGuard continuing to serve as the underlying tunnel;
• Clash Verge Rev / FlClash handling smart traffic splitting;
• DNS and GEOSITE rules being gradually refined;
• Ubuntu / Android clients being gradually optimized for auto-start and stability.

I also recorded in the series of articles that Wstunnel can encapsulate WireGuard’s UDP traffic into WSS traffic, running it through port 443 to make it look more like normal HTTPS traffic, thereby improving connection stability.

That is to say, this was not a victory for a single provider, but the result of an architectural upgrade.

11. The Complexity of a Self-Built VPN Differs Across Client Environments

Commercial VPNs usually package Windows, macOS, Android, and iOS clients nicely.
Users only need to log in, select a node, and click connect.

But self-built VPNs are different.

The actual complexity varies greatly across different operating systems’ client environments.

1. Windows Desktop

I previously used the ZgoCloud + Wstunnel + Clash Verge Rev solution on Windows, and the overall experience was quite stable.

The advantage of the Windows desktop is that the client ecosystem is fairly complete, many tools have GUIs, and troubleshooting is relatively intuitive.

The downside, however, is that if you configure WireGuard, Wstunnel, and Clash Verge Rev separately, you need to understand the relationships between them:

• WireGuard handles the tunnel;
• Wstunnel handles encapsulation;
• Clash Verge Rev handles traffic splitting;
• Whether browsers and applications go through the proxy also depends on system proxy settings and application behavior.

2. Ubuntu Desktop

After migrating to Ubuntu, I wrote “Boot Auto-Start VPN Configuration for ZgoCloud + Wstunnel + Clash Verge Rev on Ubuntu 26.04“.

Ubuntu’s advantage is that the system level is more transparent; systemd, logs, processes, and ports can all be directly troubleshooted.

The downside is that many things need to be configured manually:

• How to auto-start wstunnel;
• How to keep Clash Verge Rev running long-term;
• Whether the systemd service path is correct;
• Whether the VPN can automatically recover after a reboot.

I also separately recorded a “Troubleshooting systemd User Service 203/EXEC Error: wstunnel Auto-Start Configuration Record“. These types of issues are usually not exposed to users in commercial VPNs, but in a self-built solution, they are maintenance details that must be faced.

Additionally, after running Clash Verge Rev for a long time, I encountered an issue with excessively high memory usage and wrote “Clash Verge from 500MB to 200MB: Ubuntu VPN Client Lightweight Optimization Practical Guide“.

This shows that a self-built VPN is not just about “being able to connect”. During long-term use, client resource consumption, system stability, auto-start, and log troubleshooting all become real issues.

3. Android Mobile

The Android side is more complex.

I later wrote “ZgoCloud + Wstunnel + FlClash VPN Configuration on Android“, and also “Complete Troubleshooting and Architecture Optimization for Google Play Update Anomalies with Self-Built WireGuard + Wstunnel on Android“.

The issues on Android are not just about “whether the VPN can connect”, but also include:

• The Termux environment;
• Running the wstunnel client;
• FlClash configuration;
• Whether Google Play correctly goes through the proxy;
• Whether DNS is correct;
• Whether GEOSITE rules are hit;
• Whether the phone system’s background restrictions affect the process.

I even wrote “Complete Record of Remote Troubleshooting for Wstunnel + FlClash on a Client’s Android Device“. These types of articles better illustrate that a self-built VPN on mobile is not a one-click setup, but a system that requires understanding.

12. DNS and Traffic Splitting Rules: The Truly Hard Part of a Self-Built VPN

When many people build their own VPN for the first time, they think that as long as WireGuard has a handshake, everything is fine.

But my later practical experience is:

Just because the VPN can connect does not mean all applications will work properly.

The most typical issues are DNS and traffic splitting rules.

1. Some Websites Being Inaccessible Might Be a DNS Deadlock

I once wrote “Solving the DNS Deadlock Issue Where “Some Websites Are Inaccessible” Under Clash Verge + Wstunnel + WireGuard“.

This type of issue is not simply a case of “the VPN is broken”.
It could be the result of multiple layers stacking: Clash, DNS, DoH, DoT, proxy rules, IPv6, fallback, nameserver, etc.

2. Google Play Failing to Update Is Not Necessarily a Wstunnel Problem

Google Play failing to update on Android was a troubleshooting experience that left a deep impression on me.

I later specifically wrote “Can’t Update Play Store Apps After Self-Building a VPN? Stop Tinkering with Wstunnel, the Problem is in the Clash Traffic Splitting Rules“.

The conclusion of this article is very important:

Some problems are not Wstunnel problems, nor are they WireGuard problems, but rather that the Clash traffic splitting rules do not correctly cover the target traffic.

Eventually, the problem was solved by adding a rule similar to GEOSITE,google,Proxy in the Clash configuration, combined with DNS optimization.

3. Gmail / Thunderbird Failing to Send Emails Can Also Be a Traffic Splitting Issue

I also wrote “Thunderbird Fails to Send Gmail Emails After Self-Building a VPN: Causes and Solutions“.

These types of issues also illustrate:
Troubleshooting a self-built VPN cannot just look at “whether web pages can open”; you must also look at specific application protocols, such as SMTP, IMAP, OAuth, Gmail API, client proxy behavior, etc.

Later, I wrote “Complete Troubleshooting Record from Thunderbird Connection Failure to Switching to a Gmail API Client“. Essentially, these types of problems are no longer purely VPN issues, but comprehensive issues of “network path + application protocol + client behavior”.

13. The Real Advantages of a Self-Built VPN Over a Commercial VPN

At this point, my understanding of self-built VPNs is different from when I started.

The biggest advantage of a self-built VPN is not that it is necessarily faster, nor that it is necessarily cheaper, and certainly not that it is necessarily more stable.

Its biggest advantage is:

Controllability.

Specifically, the controllability of a self-built VPN is reflected in several aspects.

1. Server Controllability

You can choose the VPS provider, region, line, and operating system version, and you can migrate nodes based on actual experience.

For example, I have tried Vultr, DMIT, and ZgoCloud, but this does not mean these are the only choices on the market. They are just a few samples that I have personally interacted with, written about, and experienced pitfalls with.

This point must be made clear:

This article is based solely on my real usage experience and does not represent a comprehensive VPS review of the entire market.

I do not know if there are servers on the market that are more suitable for self-built VPNs. There very well might be.
But what I can responsibly discuss right now is mainly Vultr, DMIT, and ZgoCloud, which I have actually tried, and their performance in my specific network environment.

Therefore, if I include related links to Vultr, DMIT, or ZgoCloud later in the article, it is only based on my own usage experience and deployment records, not to say that they are the optimal choices in the entire market.

2. Protocol Controllability

Commercial VPNs usually have the protocol pre-packaged, and users are only responsible for selecting a node.

A self-built VPN allows you to decide for yourself whether to use:

• Native WireGuard;
• WireGuard + Wstunnel;
• 443 / WSS encapsulation;
• Or other more complex combinations.

This means you can continuously adjust the solution based on the actual network environment.

3. Traffic Splitting Controllability

The traffic splitting capability of commercial VPNs is usually determined by the client, making it difficult for ordinary users to control deeply.

Self-built solutions can leverage tools like Clash Verge Rev and FlClash to perform more granular traffic splitting based on domain, rule sets, GEOSITE, and DNS policies.

This is also the key to how I later solved issues like Google Play failing to update, Gmail/Thunderbird failing to send emails, and some websites being inaccessible.

If you want to see my phased summary of the WireGuard + Clash Verge Rev traffic splitting solution, you can refer to “WireGuard + Clash Verge Rev to Achieve Domestic Direct Connection / Foreign Traffic Splitting (Vultr & ZgoCloud Practical Evolution Edition)“.

4. Troubleshooting Controllability

When a commercial VPN has issues, I usually do not know where to look.

When a self-built VPN has issues, although troublesome, it can at least be troubleshot layer by layer:

• Whether WireGuard has a handshake;
• Whether the port is open;
• Whether Wstunnel has started;
• Whether the Clash rules are hit;
• Whether DNS is polluted;
• Whether application traffic is going through the wrong path;
• Whether the systemd service started normally.

This is the long-term value of a self-built solution.

14. The Disadvantages of a Self-Built VPN Must Also Be Made Clear

However, a self-built VPN is not for everyone.

You could even say:

If you just want peace of mind, a self-built VPN might not be the optimal solution.

The main cost of a self-built VPN is not the server fee, but the time cost and cognitive cost.

You need to understand:

• VPS purchasing and management;
• Basic Linux operations;
• WireGuard configuration;
• Firewalls and ports;
• DNS;
• Clash Verge Rev / FlClash traffic splitting rules;
• Differences between Windows, Ubuntu, and Android clients;
• systemd auto-start;
• Log troubleshooting.

Moreover, a self-built VPN has a problem that commercial VPNs usually do not have:

Your number of nodes depends on how many servers you purchase.

Commercial VPNs usually provide nodes in multiple countries or regions, and users can freely switch between them in the client.
But a self-built VPN is different.

If I only purchase one ZgoCloud Los Angeles server, then my exit IP is primarily in Los Angeles. It is not like a commercial VPN, where you can switch to Japan, Singapore, Hong Kong, Europe, or other regions at any time.

This brings up a very practical issue:

Some websites determine whether a service is available based on the region of the exit IP.

For example, when I used the ZgoCloud Los Angeles node to access the Binance website, I encountered a prompt saying “Users in the current region are not supported”.

This was not a configuration error with WireGuard, Wstunnel, or Clash, but a side effect of the server’s exit location. Platforms like Binance and Binance.US inherently have supported and unsupported regions, and the official Binance.US help documentation also lists the states and territories where services are and are not supported.

It must also be emphasized here:

It is not recommended, nor should it be done, to use a VPN to bypass the regional restrictions of financial platforms, trading platforms, or other services.

Platforms have their own regional service scopes, compliance requirements, and risk control systems. The purpose of a self-built VPN is to improve your own network controllability, not to evade platform rules.

Therefore, an obvious disadvantage of a self-built VPN is:

Where the server is, that is where your network exit is.

If you want to have exits in multiple regions, you need to purchase multiple servers in different regions, or set up multiple nodes. This introduces new costs:

• Increased server fees;
• Increased configuration and maintenance complexity;
• Increased node health check costs;
• More complex Clash / FlClash rule configuration;
• The need to judge compliance risks for different regional services yourself.

This is also a significant difference between self-built VPNs and commercial VPNs.

Commercial VPNs package node pools, line switching, and region selection nicely;
self-built VPNs hand this control back to you, but they also hand the maintenance costs back to you.

Therefore, the real experience of a self-built VPN is:

It is not less work, but it is more controllable.

If you just want to click a button and use it, a commercial VPN is still more suitable.
If you are willing to choose your own server, understand the problems yourself, and maintain the nodes yourself, then a self-built VPN is worth trying.

15. Core Differences Between Commercial VPNs and Self-Built VPNs

16. How to Choose Between Commercial VPNs and Self-Built VPNs

If I were to summarize it again now, I would make the following judgment.

Those Suited for Commercial VPNs

If you meet these conditions, a commercial VPN might be more suitable:

• Do not understand servers;
• Do not want to maintain Linux;
• Just want to install the client and use it directly;
• Cannot accept frequent troubleshooting;
• Main need is temporary access to overseas websites;
• Willing to pay a subscription fee for peace of mind;
• Want to switch between multiple regional nodes directly in the client.

The keywords for commercial VPNs are:

Hassle-free, quick start, low technical barrier, convenient node switching.

Those Suited for Self-Built VPNs

If you meet these conditions, a self-built VPN is more worth considering:

• Have some Linux / backend / networking foundation;
• Willing to tinker yourself;
• Want to control the server and configuration;
• Need custom traffic splitting rules;
• Want to understand the root cause of problems;
• Cannot accept being completely passive after a commercial VPN suddenly stops;
• Willing to treat it as a long-term network engineering project to maintain.

The keywords for self-built VPNs are:

Controllable, adjustable, reviewable, continuously optimizable.

17. A More Practical Selection Table

18. If You Want to Continue Reading My Self-Built VPN Practical Records

If you have decided to try a self-built VPN, you can continue reading my series of articles in the following order.

1. Migrating from Commercial VPN to WireGuard

• “Full Process Review from LetsVPN Discontinuation to Self-built WireGuard VPN (With Pitfall Avoidance Guide)“

2. Early WireGuard Traffic Splitting Schemes

• “WireGuard VPN Configuration Optimization: Direct Connection for Domestic Websites, VPN for Foreign Traffic (Tested Effective)“
• “WireGuard Domestic Direct Connection + Foreign Tunnel Configuration Pitfalls and Perfect Solution (Tested Usable)“

3. Native WireGuard Troubleshooting and Port Issues

• “Full Review of WireGuard Self-Built VPN Occasional Unavailability: From Normal Use → Sudden No Handshake → Port Blocked → Port Change + Smart Traffic Splitting Complete Solution Process“
• “Ultimate Minimalist Solution for Self-Built WireGuard to Solve Frequent Port Blocking (Beginner-Friendly and Reproducible)“
• “WireGuard Handshake Normal But Can’t Open Websites? Why CN2 GIA is Necessary, with DMIT Deployment & Out-of-Stock Alternatives“

4. Wstunnel + WireGuard + Clash Architecture Upgrade

• “ZgoCloud + Wstunnel + WireGuard 4x Speed Boost, Clash Verge Rev Auto Traffic Splitting and 443 Port Anti-Blocking Practical Guide“
• “WireGuard + Clash Verge Rev to Achieve Domestic Direct Connection / Foreign Traffic Splitting (Vultr & ZgoCloud Practical Evolution Edition)“

5. Ubuntu Desktop Configuration and Long-Term Running

• “Boot Auto-Start VPN Configuration for ZgoCloud + Wstunnel + Clash Verge Rev on Ubuntu 26.04“
• “Troubleshooting systemd User Service 203/EXEC Error: wstunnel Auto-Start Configuration Record“
• “Clash Verge from 500MB to 200MB: Ubuntu VPN Client Lightweight Optimization Practical Guide“

6. Android / FlClash Configuration and Troubleshooting

• “ZgoCloud + Wstunnel + FlClash VPN Configuration on Android“
• “Complete Troubleshooting and Architecture Optimization for Google Play Update Anomalies with Self-Built WireGuard + Wstunnel on Android“
• “Complete Record of Remote Troubleshooting for Wstunnel + FlClash on a Client’s Android Device“

7. Application-Level Issues Like DNS, Google Play, Gmail

• “Solving the DNS Deadlock Issue Where “Some Websites Are Inaccessible” Under Clash Verge + Wstunnel + WireGuard“
• “Can’t Update Play Store Apps After Self-Building a VPN? Stop Tinkering with Wstunnel, the Problem is in the Clash Traffic Splitting Rules“
• “Thunderbird Fails to Send Gmail Emails After Self-Building a VPN: Causes and Solutions“
• “Complete Troubleshooting Record from Thunderbird Connection Failure to Switching to a Gmail API Client“

19. My Personal Conclusion Now

If we look at it purely from the perspective of “saving trouble”, commercial VPNs still have value.

They are suitable for ordinary users, suitable for temporary use, suitable for those who do not want to tinker, and also suitable for those who need to frequently switch nodes.

But from the perspective of “long-term controllability”, I now lean more towards a self-built VPN.

Not because a self-built VPN is necessarily simpler, but because its problems can be broken down, reviewed, and optimized.

My actual migration path was roughly:

Commercial VPN
  ↓
Lantern / LetsVPN
  ↓
LetsVPN discontinued
  ↓
Native WireGuard self-built
  ↓
Vultr / standard VPS practice
  ↓
Discovered port, line, traffic splitting, DNS issues
  ↓
Tried line concepts like DMIT / CN2 GIA
  ↓
ZgoCloud + Wstunnel + WireGuard
  ↓
Clash Verge Rev / FlClash smart traffic splitting
  ↓
Troubleshooting for Ubuntu / Android / Google Play / Gmail scenarios

Commercial VPN
  ↓
Lantern / LetsVPN
  ↓
LetsVPN discontinued
  ↓
Native WireGuard self-built
  ↓
Vultr / standard VPS practice
  ↓
Discovered port, line, traffic splitting, DNS issues
  ↓
Tried line concepts like DMIT / CN2 GIA
  ↓
ZgoCloud + Wstunnel + WireGuard
  ↓
Clash Verge Rev / FlClash smart traffic splitting
  ↓
Troubleshooting for Ubuntu / Android / Google Play / Gmail scenarios

This path was not the easiest, but it allowed me to truly understand:

A VPN is not a single-point tool, but a network system.

The server is just one layer, protocol encapsulation is another, client traffic splitting is another, and DNS and application behavior is yet another.

So, today if someone asks me:

How exactly should I choose between a self-built VPN and a commercial VPN?

My answer will not be “which is better”, but rather:

If you want peace of mind, choose a commercial VPN; if you want controllability and are willing to bear the maintenance costs, then consider a self-built VPN.

And if you decide to build your own VPN, do not pursue the so-called “ultimate solution” right from the start.

A more prudent path is:

1. First get the minimum viable version running with WireGuard;
2. Then understand ports, routing, DNS, and traffic splitting;
3. Then introduce Clash Verge Rev / FlClash;
4. Finally, consider Wstunnel, 443/WSS, line optimization, and long-term auto-start.

This way, you are not blindly copying configurations, but step-by-step building your own controllable network environment.

20. Final Words

This article is not meant to negate commercial VPNs.

On the contrary, I believe commercial VPNs remain the more reasonable choice for many ordinary users.

They are simple, hassle-free, have many nodes, and offer a more complete client experience.
If it is just for ordinary access needs, commercial VPNs still have value.

But for me, starting from the LetsVPN discontinuation, it has been hard to completely entrust my network access to a single commercial client again.

I am more willing to accept the complexity of a self-built VPN, because behind this complexity comes controllability.

However, the controllability of a self-built VPN is not free.

It requires you to understand servers, protocols, DNS, traffic splitting rules, clients, and system services.
It also brings issues like fixed exits, inflexible nodes, and higher maintenance costs.

So, my real answer now to “how to choose between a self-built VPN and a commercial VPN” is:

Commercial VPNs are for peace of mind; self-built VPNs are for controllability.
Commercial VPNs are products; self-built VPNs are systems.
Commercial VPNs hide the complexity; self-built VPNs hand the complexity back to you.

If you are like me, having a certain technical foundation and wanting to keep your network environment in your own hands, then a self-built VPN is worth trying.

But if you just want to use the network quietly, without looking at logs, modifying configurations, or studying DNS and traffic splitting rules, then a commercial VPN might still be the more hassle-free choice.