Posts

In a previous article, I introduced a fairly straightforward chained VPN setup: all devices first connect to a self-hosted WireGuard server, and the server then forwards traffic to Gluetun, which finally sends it to the Internet through an upstream VPN provider. The core value of that setup was clear: Each device only needs to be configured with WireGuard once; The upstream VPN only needs to be maintained on the server side; Phones, computers, tablets, and home devices can all be connected to the same virtual LAN; The exit IP is provided by a commercial VPN, corporate VPN, or another upstream VPN, rather than directly exposing the VPS IP; The whole system can be deployed with Docker, minimizing pollution of the host environment; Compared with connecting directly to a VPN provider, the provider only sees the exit of your VPN gateway, namely your VPS server, instead of the real IP address of each individual device; In addition, your local ISP and similar parties cannot easily tell whether you are using a mainstream VPN service, because they can only see that you are connecting to a VPN gateway, namely your VPS server. Where the traffic eventually goes remains unknown to them. However, as my use cases expanded, the original structure gradually started to reveal some limitations. The most typical issue was that traffic control was not fine-grained enough. By default, all traffic had to enter the upstream VPN tunnel, which could trigger risk-control mechanisms or cause access problems for certain services. It was also not very convenient to perform traffic engineering and apply different exit strategies to different services. Although split routing could be achieved with iptables and routing tables, the rules became difficult to maintain once they grew in number. ...

I’ve been seriously working on personal self-hosting for about five or six years now. If I’m being precise, the point when I truly started managing my own VPS can be traced even further back. The original motivation was actually very simple: there were services I used every single day, such as a password manager, music streaming, note-taking, a personal website, code repositories, and so on. Given that, why not just deploy them myself? That way, the data stays in my own hands, and I’m no longer at the mercy of subscriptions and price increases from various platforms. ...

The Beginning: My First Encounter with GnuPG (GPG) I first came across GPG around April 2021. At that time, I was just a student full of curiosity about the world of computers, with only a superficial understanding of cryptography. To me, encryption basically meant “turning text into gibberish.” But the moment I read about asymmetric encryption, where anyone can encrypt data using a public key, but only the private key owner can decrypt it, I was deeply fascinated. This concept of “trust through mathematics” struck me as elegant, rigorous, and irreversible. It was beautiful in the same way art is. From then on, I started learning GPG command-line operations, experimenting repeatedly from key generation to signature verification, trying to understand the logic behind each command. ...

Summary This article systematically documents how I turned a Raspberry Pi 5 into a minimal development and testing platform for the mainline Linux kernel (Vanilla Kernel) — including repository trimming strategies, custom kernel configuration, cross-compilation and automated deployment scripts, overlay removal techniques, and long-term synchronization with the mainline community. It’s aimed at geeks interested in the Linux mainline, ARM64 adaptation, kernel development, upstream contribution, or anyone who loves tinkering with the kernel. ...

In certain scenarios, we may need to set up a chained VPN structure: first connecting internal devices to a self-hosted WireGuard server (e.g., a personal VPS), then routing all traffic through that server to another VPN (a corporate, school, or commercial VPN service) before reaching the internet. Building this “VPN over VPN” network architecture offers the following clear advantages: Robust Privacy Protection: Internal devices’ data flows are first encrypted through a self-hosted WireGuard tunnel to your personal VPS. Then, the VPS forwards it again through a corporate or commercial VPN before finally exiting to the internet via that VPN’s IP address. This method completely avoids using the VPS’s own IP address to access target networks, greatly reducing the risk of your personal IP being tracked or leaked. ...

Recently, compliance requirements have increasingly started to affect technical work. There are frequent requests to implement compliance-related features or to complete compliance assessments. From my perspective, these requirements mainly focus on user data governance, including standardized access control and gradually giving users more control over their own data. At the same time, organizational and personnel changes are also having a noticeable impact on the system. For example, when a business domain is transferred to another department, shared resources such as databases become a point of contention. Cost allocation then becomes a practical issue. Even within the same company, internal accounting mechanisms make these discussions unavoidable, and disputes over resource usage are quite common. ...

This week, I encountered a performance issue that led me to re-evaluate the quality of some service frameworks, particularly certain Java-based ones. Under moderate load—around 35% to 40% CPU utilization—the services began to experience a large number of timeouts. This was unexpected, as neither CPU nor memory resources were saturated, and the number of worker threads was sufficient. Using Java profiling tools, I found that most worker threads were in Idle or Waiting states. There were no obvious hotspots in business logic, and no threads appeared to be fully utilized. This suggested that the bottleneck was not CPU-bound, but likely related to I/O or some form of blocking or coordination overhead. ...

This week was focused on addressing a risk identified before the holiday period. The issue involved a service that used Redis without setting TTLs for keys, instead relying entirely on Redis eviction policies. The instance was configured with an LRU-based eviction strategy, which may appear sufficient at first glance, but introduces significant risks under bursty write workloads. During periods of high write traffic, Redis is forced to aggressively trigger eviction in order to free up memory. This process consumes considerable resources, which can degrade normal operations such as read and write requests. As a result, latency at the application layer can fluctuate significantly. I have encountered this issue multiple times in production. ...

From the end of January to early February, the Chinese New Year period required on-call support to ensure system stability. During this time, the best possible outcome is simple: no incidents. Fortunately, everything remained stable, and no major issues occurred. This week, I mainly evaluated the impact of a new business requirement. One important lesson I have learned is that, when working on complex systems—especially those you are not fully familiar with—the safest approach is to minimize changes as much as possible. ...

This week was primarily focused on ensuring the stability of various services ahead of the Chinese New Year. Recently, a particular service frequently reported timeouts during peak traffic hours. I initially notified the service owner to investigate the issue. However, after several days, no clear root cause was identified. Given the severity of the alarms—with timeout rates reaching up to 20% on some nodes—I decided to step in and troubleshoot the issue myself. During this period, overall traffic had increased significantly, roughly doubling compared to the end of December, likely due to the approaching holiday. My first assumption was insufficient service capacity, so I performed a capacity expansion. ...