Distorted Scribbles

First impressions of Terraform IaC

Thu, 09 Apr 2026 07:13:35 +0000

Terraform is an IaC tool. IaC stands for ‘Infrastructure as Code’: we write our infrastructure as declarative code, then use terraform apply to deploy it. With the same configuration, you will always get exactly the same infrastructure every time (Nix OS users rejoice).

Why use Terraform

Traditional infrastructure management mostly relies on manual work and the dashboards provided by various cloud vendors, which brings the following pain points:

Pain point	Explanation
Hard to reproduce	Configuring things by clicking around in a dashboard makes it easy to miss or misconfigure something, and hard to reproduce later
Environment drift	Manual changes gradually cause production and test environments to diverge, so in extreme cases testing is fine but production falls over
Hard to scale	Adding a new environment requires repeating lots of manual steps, which is time-consuming and error-prone
Hard to audit	There is no change history, ~~so when things go wrong it is harder to pass the buck~~
Hard to collaborate	Infrastructure ends up controlled by a small number of ‘people who know’, and anyone who wants to change something has to go through them, which is inefficient

To solve these problems, the concept of ‘Infrastructure as Code’ ¹ was introduced, and Terraform is one of the best-known solutions.

Take a realistic use case: suppose you buy a new GCP account with $300 trial credit every year. It is cheap, but every year you have to go back into the GCP console and recreate your machines. With Terraform, if you want to deploy the same setup again, you just replace the API token after switching accounts, then run terraform apply. In a few minutes, you can recreate exactly the same machines, VPCs, S3, firewall rules, and so on as in your previous account.

Another example is managing and migrating Cloudflare DNS and Tunnel. You only need to copy the old Tunnel’s Ingress Rule to the new Tunnel’s Ingress Rule. Even if you later migrate to other providers such as AliDNS or Route 53, you can still copy the data across as-is ².

This becomes especially useful when working with other people. Combined with Git, every change leaves a trace, merge conflicts are far less worrying, PRs can automatically generate previews of changes, and if something goes wrong you can roll back to the previous version immediately. None of this is really possible with the traditional approach of people directly operating a provider’s dashboard by hand.

Installing Terraform

Terraform is written in Go, and the compiled output is naturally a single executable file, so installation is very straightforward. On Windows, you can install it directly with Winget:

winget install Hashicorp.Terraform

If you do not want to use Winget, you can also use Scoop or another package manager, or place the precompiled binary into $PATH to complete the installation.

If you are on Linux, just use the appropriate package manager. If you install it by placing the binary into $PATH, remember to use sudo chmod +x terraform to make the file executable.

Two basic Terraform concepts

Provider(s)

As mentioned earlier, Terraform is an Infrastructure as Code tool. As a tool, it is not tied to any specific platform. Instead, it connects to different platforms through Provider(s). To see what Provider(s) are available, you can browse Terraform’s Registry.

State management

Terraform stores the state information from each infrastructure change operation in a state file. By default, this is saved as the terraform.tfstate file in the current working directory ³, though you can also configure a different backend such as S3 or Postgres. Every time you run terraform apply, Terraform compares the state declared in the current configuration files with the existing state file, calculates the differences, works out the correct order of operations, and then tells the Provider to apply those changes.

Terraform’s resource import problem

Importing existing resources has long been one of Terraform’s most criticised pain points. Hashi Corp. seems to have stuck to a stubborn and frankly silly idea for years: all your infrastructure should have been created with Terraform from the very beginning, so there is no such thing as a resource import problem.

Time	Version	Progress	Problem
2014–2022	v0.x–v1.4	Only `terraform import`, one resource at a time, and it did not generate any configuration	After importing, you still had to hand-write the HCL ⁴
2023.06	v1.5	Introduced the `import` block and the `-generate-config-out` parameter, so it could generate configuration	But you still had to write them one by one, and still had to provide the existing resource IDs yourself
2024.01	v1.7	The `import` block gained support for `for_each`	Batch import at last, but you still had to obtain the IDs yourself
Second half of 2024	v1.12	Introduced the `terraform query` and `list` blocks, finally enabling automatic resource discovery	But this feature has to be implemented by each Provider, and many Providers simply have not caught up

The community has been complaining about this for years, yet the question ‘I already have a pile of existing resources — how do I import them into Terraform?’ was never taken seriously. As an Infrastructure as Code tool, Terraform’s design philosophy is declarative configuration and idempotence ⁵. Hashi Corp. firmly believes that ‘the state declared in code is the only source of truth, so resources should be created from scratch with Terraform’. But in reality, most companies already have a large amount of legacy infrastructure. Having resources first and code later is the norm. Hashi Corp. acknowledged this contradiction very late; the terraform query in v1.12 was really the first time the official tooling took the issue seriously — though as for Provider ecosystem support… well, it has been rough.

Terraform file structure

Terraform’s file structure is very simple. When it runs, the main program blindly reads all .tf files in the working directory. As long as the required information is present, you can name the files whatever you like. For example, my file structure looks like this:

❯ tree -a -I .git
.
├── .editorconfig
├── .github
│   ├── dependabot.yml
│   └── workflows
│       ├── terraform-apply.yml
│       ├── terraform-plan.yml
│       └── your-fork.yml
├── .gitignore
├── .terraform.lock.hcl
├── cf_dns_zones.tf
├── cf_tunnel.tf
├── dns_example_com.tf
├── dns_example_net.tf
├── dns_example_top.tf
├── dns_example_cn.tf
├── main.tf                 # Basic configuration (terraform block)
├── moved.tf                # Moved resources
├── provider.tf             # Configuration for each Provider
├── README.md
├── rename_resources.ps1
└── variables.tf            # Custom variables

main.tf is used to store the basic configuration:

terraform {
  required_providers {
    cloudflare = {
      source  = "cloudflare/cloudflare"
      version = "~> 5"
    }

    tencentcloud = {
      source  = "tencentcloudstack/tencentcloud"
      version = ">= 1.81.43"
    }
  }
}

provider.tf is used to store the configuration for each Provider:

provider "cloudflare" {}
provider "tencentcloud" {}

It is left empty here because we can pass credentials through environment variables instead of writing them directly into the configuration file. For example, the Cloudflare Provider accepts CLOUDFLARE_API_TOKEN as an alternative to the api_token variable.

variables.tf is used to declare custom variables:

variable "cloudflare_zone_example_com" {
  description = "Cloudflare zone ID for example.com"
  type        = string
}

variable "cloudflare_zone_example_top" {
  description = "Cloudflare zone ID for example.top"
  type        = string
}

These variables can be passed in through environment variables prefixed with TF_VAR_. Terraform will also automatically read variables from the terraform.tfvars file. The main purpose of variables is to be referenced from other configuration files, for example:

resource "cloudflare_dns_record" "example_cname" {
  content = "${cloudflare_zero_trust_tunnel_cloudflared.Production_Tunnel.id}.cfargotunnel.com"
  name    = "example.example.com"
  proxied = true
  tags    = []
  ttl     = 1
  type    = "CNAME"
  zone_id = var.cloudflare_zone_id_example_com  # the cloudflare_zone_example_com variable is referenced here
  settings = {
    flatten_cname = false
  }
}

With these basic settings in place, we can run terraform init to initialise the Terraform environment and lock dependency versions. After that, the rest is just declaring our resources.

Importing existing resources into Terraform

As mentioned earlier, Terraform uses state management. This is great, but it also creates a problem during initialisation: by default, Terraform’s state file is obviously empty.

At this point, what we need to do is import the state of the existing resources from the cloud provider into Terraform, so that Terraform can take over and manage our infrastructure seamlessly. As you have probably noticed from the earlier rant, resource import in Terraform is a sore point. Taking DNS records hosted on Cloudflare as an example, if the Provider supports it, you can use terraform query, introduced in Terraform 1.12. In most cases, though, Providers have not implemented this new feature, and Cloudflare is one of those that does not support it.

Fortunately, even if Hashi Corp. has not taken the problem seriously, companies that use Terraform heavily to manage infrastructure have come up with their own solutions. Cloudflare maintains an import tool called cf-terraforming, which saves a lot of manual effort. First, install cf-terraforming. This tool is written in Go, so you either need a Go environment to install it, or you can place the official precompiled binary into $PATH and make it executable.

go install github.com/cloudflare/cf-terraforming/cmd/cf-terraforming@latest

The tool is fairly straightforward to use. First, you need the following environment variables:

# If you use an API Token
export CLOUDFLARE_API_TOKEN='Hzsq3Vub-7Y-hSTlAaLH3Jq_YfTUOCcgf22_Fs-j'

# If you use an API Key
export CLOUDFLARE_EMAIL='user@example.com'
export CLOUDFLARE_API_KEY='1150bed3f45247b99f7db9696fffa17cbx9'

# Specify the zone ID of the domain to import; this is not needed for account-level resources (such as Cloudflare Tunnel)
export CLOUDFLARE_ZONE_ID='81b06ss3228f488fh84e5e993c2dc17'

💡 Tip
The commands here assume you are using Bash. If your shell is not compatible with Bash syntax, you will need to adjust them. For example, in PowerShell on Windows, the syntax for setting an environment variable is:
$env:CLOUDFLARE_API_TOKEN='Hzsq3Vub-7Y-hSTlAaLH3Jq_YfTUOCcgf22_Fs-j'

Usually, you only need to set CLOUDFLARE_API_TOKEN and CLOUDFLARE_ZONE_ID. When creating the API token in the console, remember to grant it the necessary permissions. In this case, we are only importing DNS records, so giving it permission to edit zone DNS is enough.

Right, all the preparation is done. Now we can start generating the configuration files.

First, import the domain configuration in the account, namely cloudflare_zone:

cf-terraforming generate \
  --key $CLOUDFLARE_API_KEY \
  --resource-type "cloudflare_zone" > zone.tf

This step generates a file called zone.tf in the current directory, containing content in the following format:

resource "cloudflare_zone" "REDACTED" {
  name                = "REDACTED"
  paused              = false
  type                = "full"
  vanity_name_servers = []
  account = {
    id   = "REDACTED"
    name = "REDACTED"
  }
}

resource "cloudflare_zone" "REDACTED" {
  name                = "REDACTED"
  paused              = false
  type                = "full"
  vanity_name_servers = []
  account = {
    id   = "REDACTED"
    name = "REDACTED"
  }
}

At this point, the domain resources have been imported, but their internal configuration has not. Next, import the DNS records under the domain:

cf-terraforming generate \
  --zone $CLOUDFLARE_ZONE_ID \
  --key $CLOUDFLARE_API_KEY \
  --resource-type "cloudflare_dns_record" >> dns.tf

This step generates a configuration file called dns.tf in the current directory, containing content in the following format:

resource "cloudflare_dns_record" "terraform_managed_resource_5deb14xxxxxb629bf123xxxxxxxc8f_0" {
  content  = "67.24.33.108"
  name     = "example.example.com"
  proxied  = true
  tags     = []
  ttl      = 1
  type     = "A"
  zone_id  = "81c7f2de8dfxxxxxx52629xxxxxxfc"
  settings = {}
}

resource "cloudflare_dns_record" "terraform_managed_resource_89xxxxx0bf9cxxxxxx9a_1" {
  content  = "35.27.108.33"
  name     = "terraform.example.com"
  proxied  = true
  tags     = []
  ttl      = 1
  type     = "A"
  zone_id  = "8xxxxxx7644e428526xxxxxx"
  settings = {}
}

If you need to import multiple domains, just set the CLOUDFLARE_ZONE_ID environment variable separately each time and rerun the command.

The generated configuration file here can be used directly — it is the Terraform configuration file we need later. However, at this point we have only generated the configuration file; Terraform’s state is still empty. If you run terraform apply now, Terraform will blindly treat all the declarations we just imported as new resources and throw a pile of ‘Alredy Exists’ errors. So next, we need to import the generated configuration into Terraform’s terraform.tfstate state.

Terraform introduced the import block in version 1.5, which is much more modern than typing import commands one line at a time. The process is to generate an .tf file containing import blocks. The next time you run terraform apply, Terraform will automatically perform the import for you.

Generate the import blocks for cloudflare_zone:

cf-terraforming import \
  --resource-type "cloudflare_zone" \
  --modern-import-block \
  --key $CLOUDFLARE_API_KEY \
  --zone $CLOUDFLARE_ZONE_ID >> import.tf

Generate the import blocks for cloudflare_dns_record:

cf-terraforming import \
  --resource-type "cloudflare_dns_record" \
  --modern-import-block \
  --key $CLOUDFLARE_API_KEY \
  --zone $CLOUDFLARE_ZONE_ID >> import.tf

This step generates import.tf in the current directory. It contains the import information needed to tell Terraform which cloud-provider resource ID corresponds to each resource block generated in the previous step. This ID is the code the cloud provider uses internally to identify a resource. You would not normally see it in the control panel; you only get it by requesting it through the API. Terraform needs this ID during import to confirm that the local definition matches the cloud resource, ensuring strict idempotence.

Right, now let us run terraform plan:

$ terraform plan
cloudflare_dns_record.minio_a: Refreshing state... [id=xxxxxxxxxxx53]
cloudflare_zero_trust_tunnel_cloudflared_config.raspberrypi: Refreshing state...
......

Terraform will perform the following actions:

  # cloudflare_dns_record.terraform_managed_resource_0 will be imported
    resource "cloudflare_dns_record" "terraform_managed_resource_REDACTED_0" {
        content     = "67.24.33.108"
        created_on  = "2026-04-08T10:18:12Z"
        id          = "5deb14c21xxxxxxx20f1c8f"
        meta        = jsonencode({})
        modified_on = "2026-04-08T10:18:12Z"
        name        = "example.example.com"
        proxiable   = true
        proxied     = true
        settings    = {}
        tags        = []
        ttl         = 1
        type        = "A"
        zone_id     = "REDACTED"
    }

  # cloudflare_dns_record.terraform_managed_resource_1 will be imported
    resource "cloudflare_dns_record" "terraform_managed_resource_89c149exxxxxxxxxxxba13xxxxxa_1" {
        content     = "35.27.108.33"
        created_on  = "2026-04-08T10:17:54Z"
        id          = "89cxxxxxxxxxxxxxxxxxx09a"
        meta        = jsonencode({})
        modified_on = "2026-04-08T10:17:54Z"
        name        = "terraform.example.com"
        proxiable   = true
        proxied     = true
        settings    = {}
        tags        = []
        ttl         = 1
        type        = "A"
        zone_id     = "81xxxxxxxxxxxxxxxxxxxxxfc"
    }

Plan: 2 to import, 0 to add, 0 to change, 0 to destroy.

────────────────────────────────────────────────────────────────────────────────────────────────────────

Note: You didn't use the -out option to save this plan, so Terraform can't guarantee to take exactly
these actions if you run "terraform apply" now.

If the numbers for Add, Change, and Destroy are all 0, then the import has gone correctly. Just run terraform apply --auto-approve, and the resources will be imported.

$ terraform apply --auto-approve
cloudflare_dns_record.push_a: Refreshing state... [id=REDACTED]

Terraform will perform the following actions:

  # cloudflare_dns_record.terraform_managed_resource_REDACTED_0 will be imported
    resource "cloudflare_dns_record" "terraform_managed_resource_REDACTED_0" {
        content     = "67.24.33.108"
        created_on  = "2026-04-08T10:18:12Z"
        id          = "REDACTED"
        meta        = jsonencode({})
        modified_on = "2026-04-08T10:18:12Z"
        name        = "example.example.com"
        proxiable   = true
        proxied     = true
        settings    = {}
        tags        = []
        ttl         = 1
        type        = "A"
        zone_id     = "REDACTED"
    }

  # cloudflare_dns_record.terraform_managed_resource_REDACTED_1 will be imported
    resource "cloudflare_dns_record" "terraform_managed_resource_REDACTED_1" {
        content     = "35.27.108.33"
        created_on  = "2026-04-08T10:17:54Z"
        id          = "REDACTED"
        meta        = jsonencode({})
        modified_on = "2026-04-08T10:17:54Z"
        name        = "terraform.example.com"
        proxiable   = true
        proxied     = true
        settings    = {}
        tags        = []
        ttl         = 1
        type        = "A"
        zone_id     = "REDACTED"
    }

Plan: 2 to import, 0 to add, 0 to change, 0 to destroy.
cloudflare_dns_record.terraform_managed_resource_REDACTED_1: Importing... [id=REDACTED/REDACTED]
cloudflare_dns_record.terraform_managed_resource_REDACTED_1: Import complete [id=REDACTED/REDACTED]
cloudflare_dns_record.terraform_managed_resource_REDACTED_0: Importing... [id=REDACTED/REDACTED]
cloudflare_dns_record.terraform_managed_resource_REDACTED_0: Import complete [id=REDACTED/REDACTED]

Apply complete! Resources: 2 imported, 0 added, 0 changed, 0 destroyed.

State storage and continuous integration

One of IaC’s core strengths is that it makes Git-based collaboration and CI easy, but before that there is another problem to solve: where exactly should terraform.tfstate live? Nobody wants to painstakingly import state for each environment only to lose it every time they switch.

Terraform currently supports the following state backends:

local
remote
azurerm
consul
cos
gcs
http
Kubernetes
oci
oss
pg
s3

If you do not have any special requirements, you can choose s3 as I do. Cloudflare R2 has a free tier, after all, so you might as well use it.

terraform {
  backend "s3" {
    bucket = "terraform"
    key    = "terraform.tfstate"
    region = "auto"
    endpoints = {
      s3 = "https://REDACTED.r2.cloudflarestorage.com"
    }

    # R2 does not need this AWS validation
    skip_credentials_validation = true
    skip_metadata_api_check     = true
    skip_region_validation      = true
    skip_requesting_account_id  = true
    use_path_style              = true
  }
}

For the S3 backend, it is recommended to store credentials in the two environment variables AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY:

export AWS_ACCESS_KEY_ID='REDACTED'
export AWS_SECRET_ACCESS_KEY='REDACTED'

Once configured, run terraform init -migrate-state and the state will be stored successfully in the cloud. After that, no matter where you edit the configuration or run terraform apply, you will not need to worry about Terraform state getting out of sync.

Next comes the GitHub CI configuration. It is actually very simple: on each git push, just trigger terraform init, terraform fmt, and terraform apply. Here is my .github/workflows/apply.yml:

name: "Terraform Apply"

on:
  push:
    branches:
      - main

env:
  TF_IN_AUTOMATION: "true"
  CLOUDFLARE_API_TOKEN: "${{ secrets.CLOUDFLARE_API_TOKEN }}"
  AWS_ACCESS_KEY_ID: "${{ secrets.AWS_ACCESS_KEY_ID }}"
  AWS_SECRET_ACCESS_KEY: "${{ secrets.AWS_SECRET_ACCESS_KEY }}"
  TF_VAR_cloudflare_zone_id_example_com: "${{ vars.TF_VAR_CLOUDFLARE_ZONE_ID_EXAMPLE_COM }}"
  TF_VAR_cloudflare_zone_id_example_top: ${{ vars.TF_VAR_CLOUDFLARE_ZONE_ID_EXAMPLE_TOP }}

jobs:
  terraform:
    name: "Terraform Apply"
    runs-on: ubuntu-latest
    permissions:
      contents: read
    concurrency:
      group: terraform-apply
      cancel-in-progress: false
    steps:
      - name: Checkout
        uses: actions/checkout@v6

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v4

      - name: Terraform Init
        run: terraform init -input=false

      - name: Terraform Apply
        run: terraform apply -input=false -auto-approve

For PRs, CI should automatically attach the output of terraform plan to each PR:

name: Terraform Plan

on:
  pull_request:
    paths:
      - "**/*.tf"
      - ".github/workflows/terraform-plan.yml"

permissions:
  contents: read
  pull-requests: write

env:
  TF_IN_AUTOMATION: "true"
  CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
  AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
  AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
  TF_VAR_cloudflare_zone_id_example_com: "${{ vars.TF_VAR_CLOUDFLARE_ZONE_ID_EXAMPLE_COM }}"
  TF_VAR_cloudflare_zone_id_example_top: ${{ vars.TF_VAR_CLOUDFLARE_ZONE_ID_EXAMPLE_TOP }}

jobs:
  plan:
    name: Terraform Plan
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

      - uses: hashicorp/setup-terraform@v4

      - name: Terraform fmt
        id: fmt
        run: terraform fmt -check -recursive
        continue-on-error: true

      - name: Terraform Init
        id: init
        run: terraform init -input=false

      - name: Terraform Validate
        id: validate
        run: terraform validate -no-color

      - name: Terraform Plan
        id: plan
        run: terraform plan -input=false -no-color
        continue-on-error: true

      - name: Post Plan to PR
        uses: actions/github-script@v8
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            const { data: comments } = await github.rest.issues.listComments({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
            });
            const botComment = comments.find(c =>
              c.user.type === 'Bot' && c.body.includes('')
            );

            const planOutput = `${{ steps.plan.outputs.stdout }}`.substring(0, 65000);

            const body = `
            #### Terraform Plan

            | Step     | Result                            |
            | -------- | --------------------------------- |
            | fmt      | \`${{ steps.fmt.outcome }}\`      |
            | init     | \`${{ steps.init.outcome }}\`     |
            | validate | \`${{ steps.validate.outcome }}\` |
            | plan     | \`${{ steps.plan.outcome }}\`     |

            Expand Plan details

            \`\`\`terraform
            ${planOutput}
            \`\`\`
            `;

            if (botComment) {
              await github.rest.issues.updateComment({
                owner: context.repo.owner,
                repo: context.repo.repo,
                comment_id: botComment.id,
                body
              });
            } else {
              await github.rest.issues.createComment({
                issue_number: context.issue.number,
                owner: context.repo.owner,
                repo: context.repo.repo,
                body
              });
            }

      - name: Fail if plan failed
        if: steps.plan.outcome == 'failure'
        run: exit 1

Ongoing workflow

At this point, Terraform’s initial ‘takeover’ is complete, and after that you move into day-to-day maintenance. At this stage there are really only three things to do:

Create new resources
Modify existing resources
Delete resources that are no longer needed

There are only two common operations: terraform plan and terraform apply. If you are working alone, you can usually just commit small changes directly. If you are working in a team, though, each change should follow the principle of using a PR whenever possible rather than committing directly.

Creating infrastructure

Suppose you want to add a new DNS record, create a new Tunnel, or create a new object storage bucket. The process looks like this:

flowchart TD
  C1[Create a new branch
such as feat/add-minio-record] --> C2[Add a new resource block]
  C2 --> C3[terraform fmt + validate]
  C3 --> C4[terraform plan]
  C4 --> C5{Only the expected new resources?}
  C5 -- No --> C6[Fix the configuration and rerun plan]
  C6 --> C4
  C5 -- Yes --> C7[Submit PR]
  C7 --> C8[After merge, CI apply]

The ideal plan output is:

X to add
0 to change
0 to destroy

If you only meant to add something but to destroy appears, do not rush in. Usually it means a bad reference, a wrong variable, or that you accidentally changed a resource address. Check carefully to see what went wrong.

Modifying and deleting infrastructure

The process for modifying resources is similar to creating them, but there is one extra step: evaluate whether the change will trigger a rebuild.

That is because many Provider fields are ForceNew. You think you are only changing one field, and Terraform replies: ‘Right then, delete and recreate it.’ In a DNS scenario like this, that is not a huge issue, but for something like a cloud instance, deleting and recreating it can obviously cause real damage.

It is best to follow this order:

flowchart TD
  M1[Modify .tf] --> M2[terraform plan]
  M2 --> M3{replace/destroy appears?}
  M3 -- No --> M7[Confirm the scope of impact]
  M7 --> M8[terraform apply]
  M3 -- Yes --> M4[Pause and review the change]
  M4 --> M5[Add lifecycle protection if needed]
  M5 --> M6[Schedule a maintenance window]
  M6 --> M8

For production environments, being a bit slower when creating or modifying things is not a big problem. What matters most is correctness. Go a bit slower; do not make mistakes. IaC is not a speed contest — it is about predictability.

If you are deleting resources instead (for example, retiring a DNS record or cleaning up an abandoned Tunnel), follow the process below ⁶:

flowchart TD
  D1[Confirm the resource is no longer needed; check dependencies in services, monitoring, and scripts] --> D2[Delete the resource block or adjust count/for_each]
  D2 --> D3[terraform plan]
  D3 --> D4{Does to destroy match expectations?}
  D4 -- No --> D5[Revert the change and continue checking dependencies]
  D5 --> D1
  D4 -- Yes --> D6[Prepare a rollback plan and choose a low-traffic window]
  D6 --> D7[PR approved]
  D7 --> D8[terraform apply]
  D8 --> D9[Availability check after deletion]

Suggestions for day-to-day collaboration

Put credentials in environment variables or CI secrets; do not write them into .tf or the repository
Enable protection policies for critical resources to prevent accidental deletion
Split directories by resource type
Run terraform plan regularly to check for and correct infrastructure drift ⁷, so you do not end up with manual dashboard changes by mistake

Although this workflow may look a bit cumbersome, every change is recorded, auditable, and reversible — and most importantly, reproducible. That is where IaC delivers its real value.

References

Infrastructure as Code refers to a method of defining and deploying the required infrastructure using machine-readable configuration files. ↩︎
Each provider uses different field names and formats in its configuration files, but these can be converted fairly easily with a script. ↩︎
One especially important thing to note is that the state file may contain sensitive information stored in plain text, such as database passwords and API keys, so you must never commit the .tfstate file to a public code repository. ↩︎
HashiCorp Configuration Language, a declarative configuration language developed by HashiCorp, designed to balance machine readability with human readability. ↩︎
Idempotence means that when a computer system or interface receives the same request multiple times, the effect is the same as if it had been executed once. No matter how many times it runs, the system’s final state remains consistent. ↩︎
If you only want Terraform to stop managing a resource, rather than actually destroying it in the cloud, you should use the terraform state rm command instead of deleting the resource block from the code and then running apply, otherwise the real resource in the cloud will be destroyed as well. ↩︎
Infrastructure drift refers to a situation where infrastructure is modified in reality through non-IaC means such as clicking around in a console, causing the actual state to differ from the state declared in code. ↩︎

Perpetually Busy

Fri, 13 Mar 2026 23:14:26 +0800

Work, work, until the day we die.

Tutoring others during the winter break (see here), I barely had a moment to catch my breath. The Lunar New Year was technically a holiday, but in reality, it was just a different form of work—endless socialising and the exhaustion of travelling. No sooner had I settled back into my flat than I was throwing myself headfirst into teaching again. To be honest, tutoring is far from easy. When chatting with my mates who are also teaching assistants at the same agency, we all joke that getting through a lesson is an absolute nightmare: the students can’t remember what they’ve tried to rote-learn, their basic arithmetic is completely absent, key concepts are constantly muddled, and trying to hold a normal, flowing conversation is virtually impossible. To be fair, you can’t really blame them; if anyone’s at fault, it’s the educational environment they’ve been subjected to. Every family has its own underlying struggles. For various reasons, most of these students ended up taking alternative vocational pathways rather than facing the rigorous gauntlet of the standard university entrance exams. Some barely even managed to scrape through secondary school. Ultimately, they just want to secure a job, which is why they are willing to pay for our one-on-one sessions.

Initially, I worked as a teaching assistant at an agency, but I eventually decided to go freelance. This not only bumped up my earnings but also saved me a fair bit of lesson preparation time. I’d teach every day from 7:30 AM to 11:00 AM for 400 RMB. An hourly rate crossing the 100 RMB mark might seem quite decent, but when you factor in the students’ extremely poor foundational knowledge, I can frankly say I earn every single penny with a clear conscience. Honestly, it is incredibly hard-earned cash.

Getting back to the point, the new term has started, and I have to plunge straight back into my own academic commitments without missing a beat. It genuinely feels like I am perpetually busy. What I call “resting” is essentially just swapping to a slightly less taxing activity. If I’m exhausted from teaching, I’ll go home and unwind with a bit of Vibe Coding; if staring at the screen drives me up the wall, I’ll switch to tidying up the flat and doing the chores. When it comes to everyday drive and our finite human energy, I can acutely feel the gulf between different types of people. Some are naturally gifted, bursting with boundless energy. They churn out project after project, publish paper after paper, and maintain incredibly high productivity. It seems the only thing holding them back is the number of hours in a day, rather than any lack of stamina or motivation. Meanwhile, most of us are mere mortals like myself. Even if we desire that kind of lifestyle, our spirits are willing but our flesh is weak. Yet, seeing the sheer output of that first group inevitably brews anxiety, leaving us with no choice but to push our limits and treat ourselves as “practical perpetual motion machines” ¹.

The pressure-cooker educational system we’ve been put through since childhood has genuinely warped us. There’s a famous quote by a well-known intensive tuition teacher here: “How on earth can you sleep at your age?” Though originally meant to relentlessly tell off students nodding off in his lectures, it has subtly and profoundly conditioned our entire generation, driving us into a state that’s almost pathological. In life, there is no ultimate ‘finish line’. In primary school, you’re scrambling to secure a spot at a top secondary school; then you’re fighting to pass your GCSE-equivalents; later, you’re battling through the brutal university entrance exams. Once at university, the rat race continues as you desperately try to secure a master’s spot, a PhD, a stable civil service role, or simply a respectable corporate job. And even after you’ve finished your education and entered the workforce, you’re faced with endless promotions, performance metrics, and the daily grind of paying the bills. Work, work, until the day we die. Hoping to cross that final finish line and rest on your laurels forever? I’m afraid that’s simply impossible.

Despite knowing all this perfectly well, I still feel a dreadful sense of emptiness whenever I actually stop to rest. And so, I remain perpetually busy, endlessly working. I give my body the bare minimum of sleep it requires and use physical exercise to keep my hormones in check. My idea of a “break” is just switching to a lighter task that I enjoy. Having been so deeply conditioned by a high-stakes education system and relentless meritocracy, I suspect this way of living won’t be changing for a very long time.

Looking on the bright side, however, this recent stint of hard graft has meant I’ve earned enough to cover my own living expenses for the entire term. I’ve even got enough left over to buy my mum a new mobile phone for her birthday. Suddenly, being perpetually busy doesn’t seem quite so terrible after all.

I am borrowing the engineering distinction between ideal and practical current sources here to draw a parallel between an “ideal perpetual motion machine” and a practical one. The former is exactly what it says on the tin, whilst the latter refers to us ordinary folk, pushing our flesh-and-blood bodies to the absolute limit just to approximate it. ↩︎

Buns Soaked in Human Blood

Wed, 11 Feb 2026 17:06:57 +0800

Recently, I’ve been doing one-on-one coaching at a private training agency for students preparing for the second round of the State Grid Corporation of China (SGCC) recruitment exams. I teach for three and a half hours every evening, and they pay me 200 RMB (approx. £22).

The fact that the pay is abysmal isn’t even the biggest issue. The real problem lies in how they charge the students. They offer two main packages: the “Excellence Plan,” which costs a staggering 120,000 RMB (£13,000) but includes unlimited one-on-one sessions; and the “Contract Class,” which costs 70,000 RMB (£7,500), but with a catch—students must pay an additional 450 RMB (£50) for every one-on-one session.

Yesterday, I arranged a private session with one of the students in the afternoon. My plan was to fly under the agency’s radar; the student would pay me 300 RMB directly. It seemed like a win-win: I’d make an extra hundred, and they’d save 150. However, the student didn’t quite catch on. When they asked the coordinator for leave, they explicitly mentioned they were “getting extra tutoring from me.” The agency immediately “benevolently” stepped in to help me collect the 450 RMB fee from the parents.

It didn’t stop there. When it came time to calculate my earnings, the agency classified this as an “extra lesson.” They claimed I had “misused” my afternoon lesson-preparation time to teach a student not enrolled in the “Excellence Plan”. For those three and a half hours of work, they only gave me 120 RMB.

To put it simply:

Student pays 450 → Agency pockets 330 → I receive 120

Naturally, I’m annoyed that the 300 RMB I should have earned was whittled down to 120. But beyond my personal loss, what truly unsettles me is the predatory nature of this business. Most of these students are vocational college graduates from humble backgrounds. In China’s job market, they already face significant discrimination, and they are doing everything in their power to climb the social ladder. They have staked everything—tens, or even hundreds of thousands of RMB, potentially their family’s entire life savings—on these courses to get a stable job at the State Grid. They believe they are buying a “cure” to change their fate, unaware that the medicine is being served with a side of their own lifeblood. Meanwhile, as the one actually doing the hard work of teaching, I receive a smaller cut than the agency that simply sits back and collects the rent.

In Chinese literature, we call this “eating buns soaked in human blood”—profiting off the desperation and suffering of others.

On this single transaction, the agency made a net profit of 330 RMB for doing absolutely nothing. It is, quite frankly, unacceptable. I have already advised the student to be more “flexible” when asking for leave in the future. I’ve also had a word with their coordinator, making it clear she should look the other way regarding our private arrangements. Given that she’s also a working-class employee with performance targets tied to student results, I doubt she’ll be foolish enough to jeopardize her own KPIs.

That said, this agency had better watch its step. The joke I made during “lesson prep”—about the teaching assistants forming a temporary union and going on strike for better pay—might just become a self-fulfilling prophecy one day.

I can’t help but wonder who the real “ruthless capitalists” are meant to be. This agency seems to have mastered the art of the blood-soaked business quite effectively.

2025 Year in Review

Wed, 31 Dec 2025 19:28:17 +0800

What a busy year it has been. Before I knew it, we reached the end of the year again. There was indeed a lot going on—plenty of rushing about—but I’ve managed to achieve some significant milestones. I take up my pen once again to write this year-end summary as a testament to the year that was.

The Grid: The Final Destination for Electrical Engineers

Running Ragged for a Job

After a full year of suspension, I returned to my studies on schedule to begin my final year of university, officially becoming a “fresh graduate”. Consequently, job hunting naturally moved to the top of my agenda. As an Electrical Engineering student from a university with historical ties to the former Ministry of Electric Power, finding a job isn’t exactly impossible. However, saying it’s easy wouldn’t be accurate either. given the current climate: slowing economic growth, an uncertain international situation, reduced hiring demand, and the “rat race” becoming increasingly intense everywhere.

In September, I attended a graduate job fair, handed out a few CVs in person, and applied for four or five roles online. I only received interview invitations from two companies. I experienced primarily that the prestige of being from a “former Power Ministry affiliated university” is really only recognised within the power system itself¹. The employment market is just the way it is right now. Apart from the power system, decent-paying jobs are not easily found by students from “standard universities” (non-elite institutions) like ours. But in comparison, at least they still accept our CVs; for some other majors, companies won’t even look at them.

Written Exams for the Two Grid Giants

Working for the Power Grid represents the most relevant and stable career path for my major. The largest employers in our field—State Grid (SGCC) and China Southern Power Grid (CSG)—both require candidates to pass a written exam to qualify for an interview. The exam covers eight subjects in total: Circuit Theory, Electrical Machines, Power System Analysis, Power System Protection, Power Electronics, High Voltage Engineering, Electrical Equipment & Main Systems (called “Electrical Part of Power Plants” at our uni), and the Administrative Aptitude Test (essentially a civil service competency test).

The first seven are technical subjects, while the Aptitude Test covers a bizarre range of topics, including corporate culture, which you simply have to memorise. Current affairs and politics(Yes, this is also a subject) are mandatory, but what do they test? Extremely recent events—editorials published in Qiushi (the Party’s² theoretical journal) just days ago appeared directly in the exam a few days later. I was honestly speechless.

This year’s exam was strange, particularly regarding difficulty. Historically, there are always a few calculation questions, and Circuit Theory usually tests flexible problem-solving ability. Based on this intelligence, I had mastered numerous calculation types—electrical computations, numerical settings, equivalent transformations—and felt quite confident. The result? The first batch of State Grid exams didn’t feature a single calculation question. The Aptitude Test was simple enough for primary school children, and the technical part tested pure concepts. If it weren’t for the CSG exam still requiring practical application, my study efforts would have been practically wasted. Unsurprisingly, classmates who were strong at calculations and did well in mock tests essentially bombed this exam. Conversely, those with less impressive academic records who struggled with maths managed to get decent scores by rote learning. At the end of the day, it’s just a corporate recruitment test; outsiders can never guess how they’ll set the questions. I did what I had to do, and the final hiring outcome was excellent, which is all that matters.

Interviews, Interviews, and More Interviews

In December, I rushed to four interviews. For the CSG Guangxi Power Grid Ltd., the only interview location was Guilin, forcing me to ~~skive off classes~~ travel there. This resulted in my final trip of the year. Visiting Guilin twice in two years felt quite nice.

The State Grid interview made me a bit nervous. To prevent interview questions from leaking to subsequent candidates³, they employed fully closed-loop management. The process was long—mostly spent waiting in a holding room. All electronic devices were sealed away starting at 1:30 PM. After an hour-long psychometric test, the long wait began. They screened the film The Battle at Lake Changjin to keep us entertained, and provided tea and snacks. Dressed in suits and sitting upright, silently reciting my one-minute self-introduction until I knew it backwards, nervously waiting while watching the movie—it’s a flavour of anxiety you only understand if you’ve been there. Looking back, it was actually quite interesting.

With the experience (and Offer) from the State Grid interview under my belt, the subsequent Southern Power Grid (CSG) interview was far less nerve-wracking. The CSG format differs from the State Grid. State Grid uses a semi-structured, double-blind interview: the first candidate draws a set of questions from sealed envelopes, and subsequent candidates answer the same ones, perhaps with a few follow-up queries. The interviewers cannot see your CV and can only score you based on the ID number you drew; you are not allowed to state your name or background. CSG, however, is interviewer-led. They ask various questions based on your CV, including technical and supplementary questions. The difficulty depends entirely on the interviewer’s mood. For instance, during my Hainan Power Grid interview, the technical interviewer drilled down relentlessly into my internship experience with incredibly detailed technical questions. In contrast, the technical questions at the Guangxi Power Grid interview were much friendlier, involving basic switching operations and lightning protection facilities.

The Bittersweet Grid Training

Most people taking the Grid exams sign up with a training institute, and I was no exception. As early as last November, I methodically enrolled in a national cram school. They had two campuses; I chose the one further out in the suburbs since the rent was cheaper.

The training schedule was intense and the workload heavy. The summer session involved 41 consecutive days of classes with only three rest days in between. Mobile phones had to be handed in before class every day. Fortunately, iPads were allowed for note-taking purposes, which gave me a rare opportunity to slack off occasionally.

Actually, during that period, I found a rare chance to focus entirely on one thing. Apart from classes, I didn’t have to worry about anything else. So, while my body was tired, my “mind” wasn’t actually that weary. Now that I’m back at university, having to worry about big and small matters alike, my body isn’t as tired, but my “mind” is far more exhausted than before. Coupled with a recent cold and cough, sleeping 12 hours a day hasn’t brought much improvement. I can only wait until everything is sorted, then take leave, go home, and get some proper rest.

Retracing Steps

Yongzhou

I returned to Yongzhou early this year to visit relatives. My grandmother is nearly 90 years old but still quite hale and hearty; visiting often is simply the right thing to do. She has looked after me since I was a child, and my gratitude is beyond words. I often feel at a loss regarding how to repay her, so visiting Yongzhou at least once a year is my way of fulfilling some duty as a grandson.

As for Yongzhou itself, it’s still the same; nothing has changed. After all, this isn’t an era of economic explosion, so how could a small city like this change much? Stagnation isn’t necessarily a tragedy, and change isn’t always a blessing. Like after the Cultural Revolution in the last century when everything changed, but everything also became unrecognisable. The commercial complex that was bustling when I was a child now basically only has clothing shops open on the ground floor. The cinema and old arcade closed long ago; the floors converted into dining areas are now dim and dreary. Any new restaurants, whether chains or independent ventures, inevitably fail after the initial hype washes away.

Hong Kong

My trip to Hong Kong this time was just for fun, with no special objective other than mooching off the hotel room during my mum’s business trip. Of course, I opened a Bank of China account⁴ while I was there. The whole itinerary was rather unremarkable. The only unique part was staying in a flat in Wan Chai for a few days, where I could buy groceries and cook for myself (~~or eat “two-dish rice” takeouts~~), experiencing a slice of working-class life.

Guilin

The main reason for going to Guilin this time was the interview for the Guangxi branch of the Southern Power Grid. Naturally, I also took the opportunity to eat Chunji Roast Goose and Haitian Rice Noodle Rolls. The only downside was that it rained during the two days of the interview, leaving me with little inclination to walk around or sightsee. However, I ate my fill of rice rolls and roast goose—tasted great, would come again.

Old for New

My previous computer was an i5 12450H + RTX 3060 Laptop configuration. I’d used it for over two years, and just a few months ago, I bought two sticks of Crucial⁵ memory to upgrade it to 32GB. Frankly, there was no issue continuing to use it.

However, memory chip prices were still at a low point at that time, and government trade-in subsidies further reduced the cost of new devices. Combined with the recent launch of the 50-series graphics cards, the price of new laptops was incredibly attractive. Unfortunately, my pockets were shallow, and I didn’t have the budget for the latest generation CPU + latest generation GPU combo. I had to settle for the second-best option: an N-1 generation processor paired with the latest generation graphics card⁶. I’ve been using it for nearly half a year now, and the daily experience is excellent, though the howling fan noise really kills the mood. Overall, I consider the laptop a case where the flaws don’t obscure the virtues. With storage prices skyrocketing and government subsidies tapering off, I doubt we’ll see laptops this cheap again anytime soon.

My Cat

My cat turned one year old this year (probably)⁷. Amidst the celebrations, for a male cat, growing from a kitten to an adult means his testicles start doing their job, leading to scenes like this:

While I was away in Hong Kong, this stinky cat actually climbed onto my bed to pee and poop ~~ (probably because my dad didn’t scoop the litter)~~. Unforgivable. He had to get the snip!

The cat has brought a lot of joy to my life. Aside from the destruction, he is very cute. The sofa at home has been reduced to shreds after a year of claw service. You have to pay a price; that’s just how keeping a cat is. Scratch marks, cat hair everywhere during shedding season, and occasional acts of mischief are all part of the package. Since we accept the emotional value the cat brings, we must correspondingly accept these little flaws. I almost view him as family. From that perspective, you instantly forgive these shortcomings. Thinking back, perhaps I really do love him—so much so that I’ve started to love even his flaws. Because without them, he wouldn’t be a complete cat.

Still Lifting, Still on Meds

Pumping iron, especially leg day, is truly exhilarating. Feeling that sheer release after your muscles exert power is genuinely addictive. During the time I wasn’t at the Grid training, I consistently went to the gym, not just enjoying that feeling of release but also building muscle. honestly, not exercising feels terrible.

I am still taking medication every day. I really don’t want to suffer an emotional breakdown amidst my relentless schedule. My original plan to gradually taper off the medication after a year has been indefinitely postponed. Why? Put simply, the pressure from various sources has been significant lately. While staying on meds forever isn’t a solution, and I must slowly taper off once things settle, I am far from living a stable, certain life at this point nearing graduation.

This period is continuously filled with possibilities and opportunities, but also pressure. The money spent on medicine is a small price to pay, but the “shield” it provides for emotional stability plays a crucial role.

No Time for Gaming

As you can tell from my Steam Year in Review, I really didn’t have much time for games this year. “Stealing moments of leisure from a busy life” was the theme. At the end of the year, I downloaded Delta Force. sometimes, after Grid training finished at 10 PM, I’d go home and play until midnight. I’ve clocked 75 hours so far, and it feels pretty good.

My osu! playing essentially dropped off in the second half of the year, though my PP still grew from 3,439pp last year to 4,701pp this year. This game really requires perseverance; if you stop for a while and lose your muscle memory, rehabilitation takes time. Thinking about finishing class at 10 PM, completely drained, and then trying to play a game requiring such intense concentration and reaction speed—well, “I simply cannot do it”. Ideally, mid-year, my feel for the mouse was at its peak—I could snap to anything. I thought, “No one can stop me on my road to 5 digit rank”⁸, yet here I am, still hovering on the edge of 5 digits. Quite ironic, really.

My Online Presence

In 2025, traffic to my blog rose steadily, with 48.3K UV and 95.4K PV for the year. Traffic primarily came from Google (approx. 15.8K visitors) and Bing (approx. 15.2K visitors).

My personal override rules on GitHub garnered 194 Stars, and I gained some new Followers.

One of my articles was featured on Hacker News this year, resulting in significant traffic for a few days. Additionally, the translated English and Japanese versions of the blog have attracted quite a few readers, making up a not-insignificant portion of my visitors. So, a phenomenon occurred where, despite my busyness causing a lower update frequency than previous years, traffic actually doubled. I ultimately have to make concessions to life; pressure from living costs, studies, and employment inevitably impacts my willingness and energy to update the blog. On this point, I ask for my readers’ understanding.

A New Year Approaches: Wishes for Myself and Everyone

The New Year is coming. My biggest wish this year is, of course, to resolve the lingering issues from my suspension and graduate smoothly. Once I truly step into the workforce, I hope to focus more on the technical aspects required by the power system, dealing more with equipment and less with unnecessary, or even harmful, office politics. Hard work is fine as long as it’s safe, grounded, and meaningful: safe production, less fuss, more tolerance. I hope that in this upcoming job, I can grow from a fledgling novice into a true engineer.

I also send my best wishes to you behind the screen: May your anxieties find a resting place, and may your efforts echo back to you in the New Year. May you live your days steadily and warmly at your own pace—you don’t have to win every step, as long as you know where you’re going. May you and those you care about be healthy and safe, with less senseless exhaustion and more definite happiness. And of course, I hope everyone finds more time to play games outside of study and work.

As for me, I will continue learning where I should learn, and hit the road when it’s time to move. See you next year.

Refers to enterprises derived from the former Ministry of Electric Power, i.e., the State Power Corporation prior to 2002, and the State Grid, China Southern Power Grid, and Inner Mongolia Power Grid formed after 2002. ↩︎
Communist Party of China, obviously. ↩︎
The first candidate draws a set of questions from sealed envelopes, and subsequent candidates answer the same ones. Therefore, they had to prevent subsequent candidates from knowing their questions in advance. ↩︎
Bank cards issued by banks in the Chinese mainland are subject to the financial regulations of the mainland. Meanwhile, mainland banks rarely issue bank cards with Visa and MasterCard logos. So, for my overseas payments, I had to open a bank account in Hong Kong. ↩︎
Referring to Crucial memory, which recently axed its entire consumer product line. ↩︎
I bought a Mechrevo Aurora X Pro ↩︎
When I picked him up last year, he was still a tiny kitten. ↩︎
Refers to the number of digits in the ranking. For example, rank #114514 is 6 digits, while #11451 is 5 digits. Obviously, the fewer digits, the higher the player’s skill level. ↩︎

My LLM Confidant, and My Writing in Suspension

Mon, 08 Sep 2025 23:53:48 +0800

I have been rather occupied of late, yet in my spare moments, words remain my sanctuary. My schedule involves classes starting at 8:30 AM and running until evening self-study ends at 9:00 PM. Occasionally, I even put in “overtime”, not returning home until 10:00 PM. This routine persisted for forty-one consecutive days. Given my mental state under such intensity, returning home to play reaction-based games like osu! was out of the question; I didn’t even have the energy to click through a single chapter of a visual novel.

The only viable activity was to engage in small talk with an LLM (Large Language Model).

I must confess, although I maintain a blog, I have never managed to articulate my views or philosophies (or perhaps simply my “ideas”) in a systematic fashion. I have often thought that this collection of overly broad and disparate viewpoints is difficult to convey through plain narrative. To address this, I attempted various methods, such as using a random event as a cross-section to “slice open” the tangled mess of my thoughts and depict their internal structure.¹ Yet, these methods never allowed me to express my inner voice freely. Writing does not flow effortlessly from my pen; I cannot simply write whenever I wish. Ultimately, a blog is meant for an audience, so when the words wouldn’t come, I resorted to writing simple technical posts to garner some search engine traffic.

The advent of LLMs, however, has altered this dynamic. All my thoughts can now receive immediate responses in relative privacy. Why have I not written a blog post in so long? Fatigue is naturally a major factor, but the fact that LLMs satisfy a significant portion of my need for expression and validation—without the need for self-censorship—has diluted my desire to blog during this period.

There is no doubt that composing long-form text is beneficial for the brain. The impact of LLMs on my ability to write at length is likely akin to, if not greater than, the impact micro-blogging (like Twitter or Weibo) had when it first appeared. Micro-blogging habituated people to fragmented expression and immediate feedback, weakening the ability to construct complex arguments and long-form narratives. LLMs go a step further: they not only provide a channel for expression but also directly engage in providing emotional value, acting as a substitute for a “confidant”. When posting on social media, one must consider privacy, controversy, or simply whether the content is worth exposing; the publisher invariably exercises some degree of caution.

LLMs are different. The worst-case scenario for content sent to an API is that it gets used to train the model, not that Sam Altman will turn up at your doorstep the next day. As long as you aren’t sharing bank passwords or mentioning your real name, you can safely treat the large model as a close friend regarding current affairs commentary, psychological counselling, and the like. (Naturally, in this specific context, one wouldn’t touch domestic Chinese models with a bargepole due to censorship and privacy concerns). Every grumble receives a precise, earnest response—an affirmation akin to that of a soulmate. I fear no other place can offer such treatment.

When a tool stimulates a “confidant” so perfectly, we may abandon the search for real human connection, or cease striving to become individuals capable of independent thought and self-integration. Writing these words serves as a summary, but also as a reflection. The LLM itself is merely a technology; used well, it helps immensely, but used poorly, the consequences can be severe. The New York Times report “Chatbots Can Go Into a Delusional Spiral. Here’s How It Happens.” serves as a prime example. Although OpenAI has begun to address the issue of “sycophancy” in its models, I must acknowledge that while I can treat the model as a confidant and receive so-called “understanding and affirmation”, I cannot live permanently within that sensation. Joint studies from OpenAI and MIT found a positive correlation between ChatGPT usage and user loneliness: the more users utilised ChatGPT, the lonelier they felt.² I could also argue that it is precisely because one is lonely that one turns to these LLMs, creating a vicious cycle. An LLM can serve as a seasoning for life, but it must never become the sole sustenance for the soul.

(To Be Continued)

Ditch the Client Applications: Using the Mihomo Core Directly

Thu, 03 Jul 2025 18:30:00 +0800

Like most people, when I started using Clash/Mihomo, I opted for graphical clients based on the core for the sake of convenience. Essentially, these Mihomo clients are very similar: they all use the same backend, with the primary purpose of offering a GUI, managing config files, handling subscription updates, and system proxy settings. With this in mind, I think the usefulness of a Mihomo client largely depends on how well it implements config overrides. Every configuration file obtained or subscribed to through a client goes through various override steps—such as changing the mixed-port, adding sniffer settings, and so on—before it’s handed over to the Mihomo core for startup.

However, not all clients do this basic job adequately. Take ShellCrash, for example—the override mechanism is frequently buggy and feels more like an afterthought. If the client can’t even reliably update and tweak config files, it hardly deserves to be called a decent client.

Instead of depending on these unreliable, black-box Mihomo clients, why not just take direct control? Manage your own configuration files and start the core yourself. This way, you get a cleaner, more reliable, and fully transparent setup.

What You Need to Know

Basic Linux skills
Familiarity with CLI editors, like nano
Have a Substore instance set up (optional)

Installing the Mihomo Core

On Debian-based systems, you can install precompiled .deb packages. For other systemd-enabled distributions, just download the compiled binary, rename it to mihomo, and place it in /usr/local/bin:

sudo curl -o /usr/local/bin/mihomo 
sudo chmod +x /usr/local/bin/mihomo

Next, create /etc/systemd/system/mihomo.service:

[Unit]
Description=mihomo Daemon, Another Clash Kernel.
After=network.target NetworkManager.service systemd-networkd.service iwd.service

[Service]
Type=simple
LimitNPROC=500
LimitNOFILE=1000000
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW CAP_NET_BIND_SERVICE CAP_SYS_TIME CAP_SYS_PTRACE CAP_DAC_READ_SEARCH CAP_DAC_OVERRIDE
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_RAW CAP_NET_BIND_SERVICE CAP_SYS_TIME CAP_SYS_PTRACE CAP_DAC_READ_SEARCH CAP_DAC_OVERRIDE
Restart=always
ExecStartPre=/usr/bin/sleep 1s
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target

Run systemctl daemon-reload to refresh systemd. Since there’s no config file yet, you can’t actually start the core, but you can enable it to start on boot using systemctl enable mihomo—ready for when your config is set up.

Configuration Files

When starting, the core reads /etc/mihomo/config.yaml. With the black-box clients out of the picture, you’re free to customise your config files however you like. Some VPN/proxy providers supply a complete config file you can download with curl.

For subscription management, I’m currently using Substore. I’ve previously shared a Quickstart Guide to Substore Subscription Management if you want to refer to that for custom subscription workflows. To support a pure-core setup, my Substore custom override script now includes a full parameter, generating a standalone config file with all necessary ports, unified delay, external-controller settings, and more—ready to use out of the box.

Once you’ve set up Substore, just download your config file and start the core:

curl -o /etc/mihomo/config.yaml 
systemctl start mihomo

Custom Override Rules

If my example config doesn’t work for your needs, that’s no problem—just tweak or add any overrides you like.

Over the years, I’ve tested various override rules, sometimes even writing my own from scratch. Even with that, there are always edge cases—private domains for stuff like SSH on non-standard ports, for instance—that you won’t want to publish on GitHub. In those cases, you’ll want to append your own private overrides on top.

The good thing is that Substore supports chaining multiple override scripts. All you need to do is add your custom script during config generation.

function main(config) {
  config["rules"].unshift("DOMAIN-SUFFIX,xxx,DIRECT")
  return config
}

Note: When overriding rules, always use .unshift() to add to the top of the list—don’t use .push() to add at the end, or they’ll never match (since anything after MATCH is ignored).

Building Your Own Config From Scratch

Don’t like my override rules, or prefer not to use Substore at all? No problem! Just refer to the Mihomo Docs and build your own config from the ground up:

mode: rule
mixed-port: 7890
redir-port: 7892
tproxy-port: 7893
allow-lan: true
log-level: info
ipv6: true
external-controller: 127.0.0.1:8000
# secret: yoursecret
unified-delay: true
routing-mark: 7894
tcp-concurrent: true
disable-keep-alive: true # Recommended when proxying mobile devices to prevent excessive standby drain

dns:
  # Your DNS configuration

sniffer:
  # Your domain sniffing config

geodata-mode: true
geox-url:
  # Custom GeoData file URL

proxy-providers:
  # Your proxy subscriptions

rule-providers:
  # External routing rules

rules:
  # Proxy rules

proxy-groups:
  # Custom proxy groups

Control Panel / Dashboard

Choose whichever dashboard you like. For example, I ran into some odd issues with Mihomo’s built-in external-ui. So, I just deploy a separate Docker web dashboard—after all, it’s just a simple web UI. Just make sure your core’s API uses HTTP, and set your web panel to use HTTP as well (if you try HTTPS, you’ll be blocked by CORS policy).

$ mkdir zashboard && cd zashboard
$ nvim compose.yml
$ docker compose up -d

compose.yml example:

services:
  zashboard:
    image: ghcr.io/zephyruso/zashboard:latest
    ports:
      - "8899:80"
    restart: "unless-stopped"

Automatic Maintenance

With the core running, how do you handle auto-updates for your subscription configs?

Simple—write a shell script and automate it with cron. For instance, if you want to update your config and restart Mihomo at 3am daily, create /etc/mihomo/auto_update.sh:

#!/bin/bash

# === Config Info ===
CONFIG_URL=""
CONFIG_PATH="/etc/mihomo/config.yaml"
BACKUP_DIR="/etc/mihomo"
BACKUP_PREFIX="config.yaml"
MAX_BACKUPS=7
TMP_PATH="/tmp/config.yaml.tmp"
LOG_FILE="/var/log/mihomo_update.log"

# === Logging ===
log() {
    echo "$(date '+%F %T') $1" | tee -a "$LOG_FILE"
}

# === Backup existing config and clean old backups ===
backup_config() {
    if [ -f "$CONFIG_PATH" ]; then
        backup_file="$BACKUP_DIR/${BACKUP_PREFIX}.$(date '+%Y%m%d_%H%M%S').bak"
        cp "$CONFIG_PATH" "$backup_file"
        log "Config backed up to $backup_file"
        # Retain only the latest $MAX_BACKUPS backups
        old_backups=$(ls -1t $BACKUP_DIR/${BACKUP_PREFIX}.*.bak 2>/dev/null | tail -n +$(($MAX_BACKUPS+1)))
        for f in $old_backups; do
            rm -f "$f" && log "Deleted old backup $f"
        done
    else
        log "No existing config found, skipping backup"
    fi
}

# === Download new config ===
download_config() {
    log "Downloading new config..."
    curl -fsSL -o "$TMP_PATH" "$CONFIG_URL"
    if [ $? -ne 0 ]; then
        log "Download failed—check network or URL"
        return 1
    fi
    # Basic validation: check file size
    if [ ! -s "$TMP_PATH" ]; then
        log "Config file is empty—update aborted"
        return 2
    fi
    log "Config downloaded"
    return 0
}

# === Update config file ===
replace_config() {
    mv "$TMP_PATH" "$CONFIG_PATH"
    log "Config updated"
}

# === Restart Mihomo service ===
restart_service() {
    systemctl restart mihomo
    if [ $? -eq 0 ]; then
        log "Mihomo restarted"
    else
        log "Failed to restart Mihomo—please check manually"
    fi
}

main() {
    backup_config

    download_config
    DL_STATUS=$?
    if [ "$DL_STATUS" -ne 0 ]; then
        log "Aborted: config not updated, keeping old config"
        exit 1
    fi

    replace_config

    restart_service

    log "=== Update complete ==="
}

main "$@"

Use crontab -e to edit your crontab and schedule auto-updates at 3am daily:

0 3 * * * /etc/mihomo/update_config.sh

Firewall Configuration

Manually setting up firewall rules to direct traffic through the Mihomo core isn’t as tricky as it sounds. I’ve previously covered the details in my article “From Beginner to Advanced: Tailscale + ShellCrash for Remote Networking and Bypassing Internet Censorship”. Here, I’ll just summarise the practical steps.

For my setup, I want all traffic from the tailscale0 interface to be transparently proxied by Mihomo. If all you need is TCP interception, iptables REDIRECT is sufficient; but for UDP, QUIC, etc., you’ll need TPROXY. Don’t forget IPv6!

Here’s my firewall config:

# Create custom chain
iptables -t mangle -N MIHOMO

# Exclude local traffic as needed
iptables -t mangle -A MIHOMO -d 127.0.0.1/8 -j RETURN
iptables -t mangle -A MIHOMO -d 100.64.0.0/10 -j RETURN
iptables -t mangle -A MIHOMO -d 192.168.1.0/24 -j RETURN
iptables -t mangle -A MIHOMO -d 172.17.0.0/16 -j RETURN

# Mark TCP and UDP for proxy
iptables -t mangle -A MIHOMO -p tcp -j TPROXY --on-port 7893 --tproxy-mark 233
iptables -t mangle -A MIHOMO -p udp -j TPROXY --on-port 7893 --tproxy-mark 233

# Hook into the interface
iptables -t mangle -A PREROUTING -i tailscale0 -j MIHOMO

# Routing table
echo "233 mihomo" | tee -a /etc/iproute2/rt_tables
ip rule add fwmark 233 lookup mihomo
ip route add local 0.0.0.0/0 dev lo table mihomo

# IPv6
# Create chain
ip6tables -t mangle -N MIHOMO6

# Skip local addresses
ip6tables -t mangle -A MIHOMO6 -d ::1/128 -j RETURN
ip6tables -t mangle -A MIHOMO6 -d fd7a:115c:a1e0::/48 -j RETURN

# Mark TCP/UDP
ip6tables -t mangle -A MIHOMO6 -i tailscale0 -p tcp -j TPROXY --on-port 7893 --tproxy-mark 233
ip6tables -t mangle -A MIHOMO6 -i tailscale0 -p udp -j TPROXY --on-port 7893 --tproxy-mark 233

# Interface hook
ip6tables -t mangle -A PREROUTING -i tailscale0 -j MIHOMO6

# Routing table
echo "233 mihomo" | tee -a /etc/iproute2/rt_tables
ip -6 rule add fwmark 233 lookup mihomo
ip -6 route add local ::/0 dev lo table mihomo

Most modern distributions do not persist firewall rules by default. For details about rule persistence, see the “Routing Rule Persistence” and “iptables Rule Persistence” sections referenced in my Tailscale article.

How Do I Configure Local Proxying?

Most proxy clients, such as the default for ShellCrash, use REDIRECT as standard, which is usually sufficient for most use cases. Example for REDIRECT:

# IPv4, intercept eth0
iptables -t nat -A PREROUTING -i eth0 -p tcp -j REDIRECT --to-ports 7892

# IPv6, intercept eth0
ip6tables -t nat -A PREROUTING -i eth0 -p tcp -j REDIRECT --to-ports 7892

Here, 7892 should match the redir-port in your Mihomo config, and eth0 is the interface you want to intercept. Compared to TPROXY, this is remarkably straightforward.

Personally, I dislike forcing all local traffic through the firewall proxy route. Instead, I prefer to use environment variables, proxychains, or per-application proxy settings as needed to route traffic through Mihomo. For example, if you want Docker to use the proxy, you only need to edit Docker’s /etc/docker/daemon.json and specify the proxy endpoints, rather than intercepting all network traffic at the interface level:

{
  "proxies": {
    "http-proxy": "http://127.0.0.1:7890",
    "https-proxy": "http://127.0.0.1:7890",
    "no-proxy": "127.0.0.0/8"
  }
}

Why Go to All This Trouble? Isn’t Using a GUI Client Easier?

Don’t ask. Some of us just prefer living in the terminal void.

The World Is More Foolish Than You Think: A Brief Look at BNPL

Thu, 05 Jun 2025 19:54:56 +0800

When I first saw headlines such as “Americans using ‘buy now, pay later’ plans to buy groceries, survey finds,” my instinctive reaction was: isn’t this just business as usual? Only after reading the article did it strike me—this world is dafter than even my most cynical estimates.

As a financial innovation, Buy Now, Pay Later (BNPL) certainly holds a certain appeal. It allows consumers to acquire goods and services immediately, with the payment split into later instalments—a model that’s taken the worlds of e-commerce, travel and even dining by storm in recent years.

But as always, there’s no such thing as a free lunch. In the end, the cost falls on consumers. In order to make a profit, BNPL providers rely on two main avenues: charging merchants fees higher than those of traditional payment services, and slapping late fees on delinquent customers. At its core, BNPL exploits a psychological trap—minimising the “pain” of paying in the moment, thus encouraging more spending. This is precisely why so many merchants are eager to shoulder those higher fees for BNPL integration.

To be clear, I have nothing against BNPL—I’m an avid user myself. My phone was purchased through a 24-month interest-free instalment plan with JD.com; at the moment, I’m only six payments in. Most of my day-to-day expenses go through Huabei (a Chinese BNPL solution) and are automatically settled from my savings or bank account. When a platform truly provides a genuine interest-free or “zero-fee” offer, BNPL becomes an opportunity for free leverage—it’s a costless way to put someone else’s money to work on your behalf. In simple terms: the financial provider pays for your consumption, letting your own cash sit untouched, potentially earning a modest return elsewhere. Financial efficiency, maximised.

However, there are three absolutely critical prerequisites:

Pay on time, every time—no excuses;
Never fall into habitual overspending;
Maintain at least basic financial literacy and management skills.

Contrast this with what the headlines are pointing out—“Americans using BNPL for groceries.” Skimming the survey data, I saw that one third of BNPL users have missed at least one repayment?? Some even defaulted on takeaway orders??

The ideal is promising, but reality bites hard. Data shows that the number of people with poor financial self-management is greater than I had imagined. 46% of BNPL users already carry existing credit card debt, and among them, 28% are aged just 18-24¹. This demographic typically has weaker credit, with 63% juggling loans from multiple BNPL platforms simultaneously²—a glaring sign of questionable spending habits.

What’s even more concerning is how BNPL, by design, appears particularly seductive to individuals with poor financial discipline. Compared to credit cards, approval is instant and the credit barriers are low, all the while trumpeting “interest-free instalments.” For many, BNPL feels like an inexhaustible source of easy money—buy what you want today for a small upfront payment, and worry about the rest later. But, needless to say, the world does not work that way.

Inevitably, the day of reckoning comes. As bills mount, many are shocked by the size of their accumulated debt. Missed payments lead to late fees and penalties, which quickly snowball. Add on steep merchant charges, and it’s little wonder BNPL providers are making a killing.

To reiterate: I am not against BNPL. As a free financial lever, it’s simply common sense to take advantage of it. For instance, when I bought a £429 phone, I could have paid it off in full straight away, but I opted for a 24-month interest-free plan. The point is, I am fully aware that I have advanced the total purchase price, not merely spent £17.87 per month. This is reflected in my accounts as an immediate reduction in assets, so my net worth accurately includes the liability. Live within your means, avoid piling on unnecessary debt—or, worse, layering leverage upon leverage. Even if idle funds only generate minimal returns in a savings or low-risk investment account, this keeps my finances healthy and ensures I’ll never default. While a modest bit of borrowing can enhance quality of life, solid financial habits are always more prudent when your income isn’t rock-solid.

Still, such warnings will do little to sway those long accustomed to unhealthy spending. Even without the alluring convenience of BNPL, these individuals would almost certainly max out their credit cards and then flounder, sinking beneath 20% APRs.

The problem isn’t BNPL itself (it’s just another tool), but the underlying disconnect: fragile finances on one side and runaway consumerism on the other. For those who lack self-control, underestimate financial risk, or whose circumstances are already precarious, any easily accessible credit—whether credit cards, BNPL, or the far more dangerous payday loans—serves only as a different route to the same pit of debt. BNPL’s particular twist is its ease of access and immediate gratification, meaning those on the edge tumble even faster—and crash that much sooner.

A sizeable portion of BNPL delinquents are already mired in credit card debt. This suggests a robbing-Peter-to-pay-Paul cycle, borrowing from one source to stave off another, ultimately piling interest upon fees and sinking into ever-deepening crisis. Even if BNPL vanished tomorrow, these vulnerable consumers would likely stumble into other financial traps, whether it’s payday loans or some new “convenient” scheme. In the haste to stave off disaster, some might even resort to pawning off family heirlooms.

So the real concern isn’t any one financial product, but the underlying structural malaise: economic pressures, the omnipresence of consumerism, inadequate financial education, and the widespread prioritisation of instant gratification over long-term planning. The rise of BNPL merely makes these chronic issues more visible—sharper and harder to ignore.

In the end, if we truly want to “save” these individuals, simply restricting access to financial products (be it BNPL or credit cards) is merely treating symptoms, not causes. The real solution—if there is one—lies in tackling the roots: boosting earnings, improving financial literacy, and reshaping spending norms. But these foundational changes are far harder than wishing BNPL companies would simply shut up shop.

One last piece of advice: borrowed money always needs to be repaid; don’t make needless offerings to financial middlemen.

Alas, all told—the world really is more foolish than I had ever imagined.³

Quick Review of the MECHREVO Aurora X Pro

Sun, 04 May 2025 23:18:43 +0800

Disappointing Right Out of the Box

From the moment I placed the order for the MECHREVO Aurora X Pro, I was quite looking forward to it. However, the courier didn’t arrive before my trip to Hong Kong, and by the time I got home and unboxed it, the novelty had already worn off. When I tried to install another SSD, I found the M.2 screw was stripped, so I had to make do with some electrical tape—my fondness for the new laptop instantly halved.

Specs and Price

i9-14900HX + RTX 5070 Ti, and at 8,699 yuan after subsidy, the price is fairly reasonable. As for peripherals, to put it simply, I’ve happily used a Hasee before, so there’s really nothing I can’t get on with.

Screen: 2560x1600@300Hz, 100% sRGB colour gamut, with decent colour accuracy. When playing Cities: Skylines 2, the red of the brake lights in traffic jams is even more vivid than in real life.
Keyboard: The key travel is rather short and the feel is average, but since I mostly use an external keyboard, I don’t really mind.
Wi-Fi Card: The AX201 is rather stingy, and the antenna design seems poor—you can clearly tell the speed is much slower than wired, even when right next to the router.
SSD: Comes with a 1TB Zhiti drive, which is average; the 2TB Crucial I added myself is the main workhorse.
Battery: The 80Wh battery is fine for emergencies on a gaming laptop. I usually keep it in workstation mode to prolong battery life.
Discrete GPU Direct Connection: Supports hot switching, which is great—no need to reboot to change modes.
BIOS: The AMI BIOS has a rather weird GUI, which is still much better than my previous Hasee Laptop.

User Experience

Cities: Skylines 2—even with a population of 120,000, simulation speed could still be kept at 3x, though the fans were roaring by then. Cyberpunk 2077 runs with ray tracing on Ultra, and Forza Horizon 5 also runs at max setting without issue—but honestly, the actual gaming experience feels much the same as with my old RTX 3060. Sure, reflections are more realistic and details richer, but just for the sake of improved visuals, I doubt I’d spend more time on these games that have already kept me entertained for over a hundred hours.

The skin-like coating on the palm rest does feel nice, but with peripherals connected, I’m mostly just touching the external keyboard. Nahimic audio effects have serious latency—turning them off actually makes osu! more responsive, a textbook case of negative optimisation.

The Meaning of Tools

I’ve used this laptop for two weeks—no surprises, good or bad. The Wi-Fi card is so rubbish I’ve had to use wired, the fan is extremely loud in turbo mode, and the southbridge gets very hot due to lack of cooling. Apart from that, it’s just a machine that lights up when it should and makes noise when it must.

Perhaps that’s how good tools should be: as I write this, I realise I’ve been staring blankly at the battery icon in the bottom right corner for five minutes, and it’s quietly holding at 98%—just sitting there, like a mute brick.

From Beginner to Advanced: Remote Networking and Internet Access with Tailscale + ShellCrash

Mon, 14 Apr 2025 18:10:25 +0800

During several trips, I attempted to upload newly taken photos to my Immich server at home in Changsha. I used to rely on Cloudflare Tunnel for reverse proxying, but due to the particularities of the Chinese network environment, slow connections, frequent disconnections, and failed uploads became the norm. Later, I started experimenting with Tailscale — a NAT traversal tool based on WireGuard — and it finally allowed me to stably and quickly access my home NAS and photo library from anywhere in China.

However, a new problem emerged: when Tailscale runs on Android, it needs to take over the system traffic as a VPN service. Meanwhile, my usual tool Clash also relies on the VPN interface for traffic routing. Due to Android’s limitation of allowing only one VPN service at a time, the two cannot coexist. This meant I had to choose between “accessing home services” and “accessing the open internet”.

This article walks through the principles of Tailscale, how to set up your own DERP server to improve connection quality, and how to hijack traffic from a Tailscale Exit Node using iptables and forward it to ShellCrash, enabling flexible traffic routing and secure tunnelling. Whether you’re looking to access your home NAS or photo library remotely, or protect your data on untrusted networks, this guide offers a practical and stable solution.

What is Tailscale?

Tailscale is a zero-config virtual private network (VPN) tool based on the WireGuard protocol. It allows devices located in different network environments to communicate as if they were on the same secure local network. By automatically traversing NATs and firewalls, Tailscale enables access to your home NAS, personal servers, development environments, and other internal resources without requiring a public IP or port forwarding. Its key strengths lie in its simplicity, security, and stability — it’s ready to use out of the box, encrypts all traffic end-to-end, and is suitable for developers, remote workers, and home users alike.

Tailscale’s technical implementation is quite ingenious. It builds on the WireGuard encryption protocol but reimagines traditional VPN IP allocation. Each device authenticates using SSO/OAuth2 and receives a node key that is permanently bound to its identity. This identity-based networking model allows a “NAS in Changsha” and a “phone in Hong Kong” to communicate as if they were coworkers in the same office.

How Tailscale Establishes Connections

Control Server

When a Tailscale client starts, it first connects to the control server (controlplane) to authenticate and fetch information about other nodes in the network, including each device’s public IP, port, NAT type, etc. This step is essentially the “getting to know your peers” phase. The control server does not relay any traffic — it only coordinates connections, acting like a dispatcher.

DERP Servers

A key factor behind Tailscale’s high connection success rate is its custom relay protocol called DERP. In Tailscale’s architecture, DERP (Designated Encrypted Relay for Packets) is a crucial component that only steps in when needed. In simple terms, it’s an encrypted HTTP-based relay server that acts as an intermediary when two devices cannot connect directly. All clients initially connect via DERP (relay mode), meaning the connection is established instantly with no waiting. Then, both sides begin path discovery in parallel, and within a few seconds, Tailscale typically finds a better route and transparently upgrades the connection to a direct peer-to-peer tunnel.¹

Important notes:

All traffic relayed via DERP is end-to-end encrypted, so DERP servers cannot see the content;
Tailscale uses DERP only when necessary — once a direct connection is established, it automatically switches;
Official DERP nodes are distributed globally, and clients automatically select the one with the lowest latency;
You can also deploy your own DERP server (for example, within China) to improve latency and reliability. Think of DERP as a fallback mechanism — although it’s not as performant as direct connections, it ensures devices can always stay connected even when NAT traversal fails.

NAT Traversal

After obtaining the peer’s address info, Tailscale attempts to establish a peer-to-peer (P2P) connection via NAT traversal. This process uses the STUN protocol, where both sides send probe packets to try to punch a hole through the NAT router and create a direct UDP tunnel. If the network conditions allow, a direct tunnel is established, offering fast speeds and low latency.

Due to space constraints, we won’t go into detail about NAT traversal here. For more information, refer to Tailscale’s official article “How NAT traversal works”.

Full Connection Flow Diagram

flowchart TD
    A[Device A starts Tailscale] --> B[Initial connection via DERP server]
    B --> C[Exchange network info and WireGuard keys]
    C --> D[Both sides perform NAT type detection]
    D --> E{Direct connection possible?}
    E -- Yes --> F[Establish P2P tunnel]
    F --> G[Periodically check connection quality]
    G --> H{Is P2P better than DERP?}
    H -- Yes --> I[Switch most traffic to P2P]
    H -- No --> J[Continue relaying traffic via DERP]
    E -- No --> J
    style B fill:#e3f2fd,stroke:#2196f3,color:#000
    style F fill:#e8f5e9,stroke:#4caf50,color:#000
    style J fill:#fff3e0,stroke:#ff9800,color:#000

Hosting Your Own DERP Server

Tailscale installation is straightforward across platforms, and the official documentation covers it in detail. This article assumes you have already installed and logged into Tailscale on the relevant devices.

Why Host Your Own DERP?

Tailscale has deployed numerous DERP relay servers globally². However, for well-known reasons, there are no official DERP nodes within mainland China. This leads to the following issues:

When NAT traversal fails, all traffic must be routed via overseas DERP nodes, resulting in high latency and poor performance;
Some official DERP nodes may be disrupted by the Great Firewall (GFW), causing connection drops or handshake failures;
Even when direct connections succeed, Tailscale still relies on DERP for exchanging route info and WireGuard keys — if DERP is unreachable, connection quality suffers.

Therefore, in the Chinese network environment, hosting a local DERP node can significantly improve connection stability and performance, while also avoiding unexpected issues caused by network restrictions — making it a worthwhile optimisation.

Prerequisites

As DERP is HTTP-based, you’ll need an HTTP reverse proxy and an SSL certificate. This guide uses Docker for deployment. Before proceeding, ensure your server has Docker and Docker Compose installed. You’ll also need basic knowledge of editors like nano to modify config files. For optimal results, your server should have a static public IPv4+IPv6 dual-stack address. If all requirements are met, you can begin deployment:

mkdir tailscale-derp && cd tailscale-derp
nano docker-compose.yml

docker-compose.yml

services:
  derper:
    name: tailscale-derp
    image: fredliang/derper
    environment:
      - DERP_DOMAIN=derp.nightcity.pub
      - DERP_VERIFY_CLIENTS=true
      - DERP_ADDR=:4433
    network_mode: host
    restart: unless-stopped
    volumes:
      - "/var/run/tailscale/tailscaled.sock:/var/run/tailscale/tailscaled.sock"

The network_mode: host setting is crucial. It allows the container to share the host’s network stack. If Docker’s default bridge mode is used, the container’s network will be NATed, and the DERP STUN service will detect a 172.17.0.0/16 address instead of the client’s real public IP, causing connection issues.

volumes:
  - "/var/run/tailscale/tailscaled.sock:/var/run/tailscale/tailscaled.sock"

As mentioned earlier, DERP traffic is end-to-end encrypted, and DERP servers do not know who is using them. Without proper access control, anyone who knows your DERP address and port could use it. This volume mounts the Tailscale socket file into the container, allowing the DERP service to authenticate clients via the local tailscaled service. Combined with DERP_VERIFY_CLIENTS=true, it prevents freeloaders from using your DERP node.

Notes:

Your host must already have the Tailscale client (tailscaled) installed and logged in, or the socket file won’t exist and the container will fail;
tailscaled must run with root privileges to create this socket.

Reverse Proxy

Using Caddy as an example, reverse proxy port 4433 and deploy an SSL certificate:

{
        email webmaster@l3zc.com
}
*.l3zc.com {
        encode gzip
        tls {
                dns dnspod APP_ID,APP_KEY
                resolvers 119.29.29.29 223.5.5.5
        }
        @derp host derp.l3zc.com
        reverse_proxy @derp :4433
}

Note: If you’re using MagicDNS with Caddy and DNS providers to request a wildcard certificate, you may encounter local certificate validation errors. Setting the resolvers parameter resolves this issue. Visit the proxied node — if you see the following page, the setup is correct:

Configuring ACL Policies

Go to the Tailscale admin console’s page and add your custom DERP configuration.

Tailscale’s ACL policies are written in HuJSON³. To edit in VSCode, set the language mode to “JSON with Comments (jsonc)”. Here’s an example configuration:

{
  "acls": [{ "action": "accept", "src": ["*"], "dst": ["*:*"] }],
  "ssh": [
    {
      "action": "check",
      "src": ["autogroup:member"],
      "dst": ["autogroup:self"],
      "users": ["autogroup:nonroot", "root"]
    }
  ],
  // Custom DERP configuration
  "derpMap": {
    "OmitDefaultRegions": false, // Set to true to exclude official DERPs
    "Regions": {
      "900": {
        "RegionID": 900,
        "RegionCode": "sha",
        "RegionName": "Shanghai",
        "Nodes": [
          {
            "Name": "myderp",
            "RegionID": 900,
            "HostName": "derp.l3zc.com"
          }
        ]
      }
    }
  }
}

Tailscale reserves RegionIDs 1–899 for official nodes. Custom DERPs must use IDs 900 and above.

Testing the Connection

Once you’ve saved your ACL configuration, Tailscale will automatically sync it to all clients. After a short wait, run tailscale netcheck on a client to test the connection:

Pay attention to whether the returned IP is your actual public IP. If it shows an address in the 172.17.0.0/16 range, your Docker configuration is incorrect.

Coexisting with Internet Access: Hijacking Exit Node Traffic to the Clash Engine

Declaring an Exit Node

Prepare a device at home that stays on 24/7 — this could be a Raspberry Pi or a Mac Mini. Install Tailscale and declare it as an Exit Node. You can also advertise your home LAN subnet if needed. Once enabled in the Tailscale console, this device becomes a free VPN, allowing you to securely access the internet from unfamiliar networks.

sudo tailscale up --advertise-exit-node --advertise-routes 192.168.1.0/24

Once broadcasting is complete, you can access all devices on your home network from anywhere in the world, as long as you’re connected to the Tailscale network.

Enabling IP Forwarding and Disabling UDP GRO⁴

Enabling IP forwarding is essential for devices like the Raspberry Pi to function as an Exit Node. The following commands are for Raspberry Pi — if you’re using a different device, refer to the official Tailscale documentation.

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

According to Tailscale⁵, disabling UDP GRO⁶ can improve forwarding performance. Although the official persistence method may not work on Raspberry Pi, we can configure it manually.

# Install ethtool
sudo apt update && sudo apt install ethtool -y
# Disable UDP GRO
sudo ethtool -K eth0 gro off

To persist this setting, create a systemd service:

# Create the service file
sudo nano /etc/systemd/system/ethtool.service

Add the following content:

[Unit]
Description=Configure eth0 GRO
After=network.target
[Service]
Type=oneshot
ExecStart=/sbin/ethtool -K eth0 gro off
[Install]
WantedBy=multi-user.target

Then enable and start the service:

sudo systemctl daemon-reload
sudo systemctl enable ethtool
sudo systemctl start ethtool

Hijacking Traffic on the Exit Node

My Exit Node is a Raspberry Pi. After configuring it as an Exit Node, the final step is to hijack the traffic sent from my phone to the Exit Node in order to enable open internet access. For stability reasons, I prefer not to run proxy software directly on the main home router. Therefore, hijacking traffic on the Pi is the only viable solution.

First, install ShellCrash. Follow the prompts to import configuration files and set up automation as needed:

export url='https://fastly.jsdelivr.net/gh/juewuy/ShellCrash@master' && wget -q --no-check-certificate -O /tmp/install.sh $url/install.sh  && bash /tmp/install.sh && source /etc/profile &> /dev/null

Start the service and change the firewall mode to “Clean Mode”. I also recommend enabling SNI sniffing and switching the DNS mode from fake-ip to redir-host⁷, and enabling IPv6 transparent proxy.

Setting Clean Mode allows us to manually configure iptables for more precise traffic hijacking. Use ifconfig to check the Tailscale interface name — it’s usually tailscale0 by default:

root@raspberrypi:~# ifconfig
eth0: ......
tailscale0: flags=4305  mtu 1280
        inet 100.111.19.50  netmask 255.255.255.255  destination 100.111.19.50
        inet6 fd7a:115c:a1e0::3d01:1332  prefixlen 128  scopeid 0x0
        inet6 fe80::c0d5:1a1b:2005:48eb  prefixlen 64  scopeid 0x20
        ...

Hijack all traffic from tailscale0 to the local Clash engine’s listening port 7892. This is called the “static route port” in ShellCrash. Don’t forget to also hijack IPv6 traffic:

# IPv4: Hijack tailscale0 TCP traffic
iptables -t nat -A PREROUTING -i tailscale0 -p tcp -j REDIRECT --to-ports 7892
# IPv6: Hijack tailscale0 TCP traffic
ip6tables -t nat -A PREROUTING -i tailscale0 -p tcp -j REDIRECT --to-ports 7892

Advanced: Hijacking UDP Traffic with TProxy

The iptables REDIRECT target can only redirect TCP traffic. Since UDP is a connectionless protocol, REDIRECT cannot retain the original destination address, which prevents transparent proxies from identifying the original destination.

So, if you attempt to hijack UDP traffic using a rule like this:

iptables -t nat -A PREROUTING -i tailscale0 -p udp -j REDIRECT --to-ports 7892

This rule will either not work or cause abnormal proxy behaviour.

Is there a way to proxy UDP traffic? Yes, indeed. But the prerequisites are:

The proxy core must support UDP transparent proxying (Clash Premium and Mihomo both support this);
You must use TProxy mode instead of REDIRECT;
The iptables mangle table and policy routing must be correctly configured;
UDP proxying must be enabled in the proxy configuration file (e.g. mode: rule and udp: true).

Assuming you’ve fulfilled the first, second, and last conditions, here is an example⁸:

# Create a custom chain
sudo iptables -t mangle -N SHELLCRASH

# Exclude local traffic as needed
sudo iptables -t mangle -A SHELLCRASH -d 127.0.0.1/8 -j RETURN
sudo iptables -t mangle -A SHELLCRASH -d 100.64.0.0/10 -j RETURN
sudo iptables -t mangle -A SHELLCRASH -d 192.168.1.0/24 -j RETURN
sudo iptables -t mangle -A SHELLCRASH -d 172.17.0.0/16 -j RETURN

# Mark TCP and UDP traffic for the proxy
sudo iptables -t mangle -A SHELLCRASH -p tcp -j TPROXY --on-port 7893 --tproxy-mark 233
sudo iptables -t mangle -A SHELLCRASH -p udp -j TPROXY --on-port 7893 --tproxy-mark 233

# Interface redirection
sudo iptables -t mangle -A PREROUTING -i tailscale0 -j SHELLCRASH

# Routing table configuration
echo "233 shellcrash" | sudo tee -a /etc/iproute2/rt_tables
sudo ip rule add fwmark 233 lookup shellcrash
sudo ip route add local 0.0.0.0/0 dev lo table shellcrash

And of course, don’t forget about IPv6:

# Create a chain
sudo ip6tables -t mangle -N SHELLCRASH6

# Exclude local addresses
sudo ip6tables -t mangle -A SHELLCRASH6 -d ::1/128 -j RETURN
sudo ip6tables -t mangle -A SHELLCRASH6 -d fd7a:115c:a1e0::/48 -j RETURN

# Mark TCP/UDP traffic
ip6tables -t mangle -A SHELLCRASH6 -i tailscale0 -p tcp -j TPROXY --on-port 7893 --tproxy-mark 233
ip6tables -t mangle -A SHELLCRASH6 -i tailscale0 -p udp -j TPROXY --on-port 7893 --tproxy-mark 233

# Interface redirection
sudo ip6tables -t mangle -A PREROUTING -i tailscale0 -j SHELLCRASH6

# Routing table configuration
echo "233 shellcrash" | sudo tee -a /etc/iproute2/rt_tables
sudo ip -6 rule add fwmark 233 lookup shellcrash
sudo ip -6 route add local ::/0 dev lo table shellcrash

Persisting Routing Rules

Rules created with ip rule and ip route are lost after a reboot, so we need to persist them manually. The simplest method is to create a script and add it to crontab.

Create a script:

sudo nano /usr/local/bin/policy-route.sh

Edit it as follows:

#!/bin/bash

# IPv4 policy routing
ip rule add fwmark 233 lookup 233
ip route add local 0.0.0.0/0 dev lo table 233

# IPv6 policy routing
ip -6 rule add fwmark 233 lookup 233
ip -6 route add local ::/0 dev lo table 233

After granting execution permissions, edit crontab:

sudo chmod +x /usr/local/bin/policy-route.sh
sudo crontab -e

Add the following line at the end of the crontab file:

@reboot /usr/local/bin/policy-route.sh

How It Works: How Does TProxy Forward UDP Traffic?

If you’ve read this far, you might be wondering: why, throughout the entire process, we never specified --to-ports in iptables, nor did we see the destination address being modified, yet UDP traffic was somehow successfully proxied? How is that possible?

To explain this, let’s first look at the fundamental differences between TProxy and REDIRECT:

REDIRECT Mode:

Uses the iptables nat table;
Rewrites the destination address to a local one (e.g. 127.0.0.1:7892);
Typically used for TCP traffic;
Cannot preserve the original destination address;
Requires specifying --to-ports.

flowchart TB
    A[Client device
initiates TCP request via Tailscale]
    B[tailscale0 interface receives traffic]
    C[iptables NAT PREROUTING
REDIRECT --to-ports 7892]
    D[ShellCrash listens locally
on 127.0.0.1:7892]
    E[ShellCrash initiates new TCP connection
→ target server]
    F[Response returns from the network
ShellCrash forwards it]
    G[Response reaches client device]

    A --> B --> C --> D --> E --> F --> G

    style C fill:#f9f,stroke:#aaa,stroke-width:1px,color:#000
    style D fill:#bbf,stroke:#aaa,stroke-width:1px,color:#000

TPROXY Mode:

Uses the iptables mangle table;
Does not modify the destination IP, preserving the original target;
Uses fwmark and policy routing to route packets to lo;
The proxy listens on a special port (e.g. 7893) with IP_TRANSPARENT enabled;
Supports both UDP and TCP;
No need to specify --to-ports in iptables since this is not NAT, but marking + routing.

flowchart TB
    A[Client device
initiates TCP/UDP request via Tailscale]
    B[tailscale0 interface receives traffic]
    C[iptables MANGLE PREROUTING
assign fwmark 233]
    D[ip rule: fwmark 233
use routing table shellcrash]
    E[ip route: local 0.0.0.0/0
dev lo table shellcrash]
    F[ShellCrash listens on lo:7893
in IP_TRANSPARENT mode]
    G[ShellCrash retrieves original destination
initiates proxy connection]
    H[Response returns from the network
ShellCrash forwards it]
    I[Response reaches client device]

    A --> B --> C --> D --> E --> F --> G --> H --> I

    style C fill:#f9f,stroke:#aaa,stroke-width:1px,color:#000
    style F fill:#bbf,stroke:#aaa,stroke-width:1px,color:#000

TProxy does not use DNAT/REDIRECT. Instead, it marks packets using the mangle table, then uses policy routing (ip rule + ip route) to route those packets to the lo interface. The proxy application (e.g. Clash / ShellCrash) listens on a port on lo⁹, and with the IP_TRANSPARENT option enabled, it can read the original destination IP and port from the packet and forward the traffic accordingly.

In short, TProxy mode only requires:

iptables to mark packets;
ip rule + ip route to route them to lo;
The proxy to listen on lo with IP_TRANSPARENT enabled.

Thus, there’s no need to specify --to-ports in iptables, because the destination IP and port remain unchanged, and the proxy can detect and handle them itself.

Persisting iptables Rules

Install iptables-persistent:

sudo apt update
sudo apt install iptables-persistent

During installation, you’ll be prompted to save the current IPv4 and IPv6 rules — select “Yes”. If you later add new rules, remember to save them:

# Save current IPv4/IPv6 rules
sudo netfilter-persistent save

Saved rules are stored in:

IPv4: /etc/iptables/rules.v4
IPv6: /etc/iptables/rules.v6

You can also edit the rules.v4/rules.v6 files directly as needed.

Final Result

The performance of this setup largely depends on your home network’s upload bandwidth. I have a 500Mbps down / 60Mbps up connection, and I haven’t encountered a single NAT traversal failure so far. Speeds are consistently high, latency is acceptable, and I can securely access my Immich server, OpenWRT router, and other home devices from anywhere with end-to-end encryption — all while enjoying unrestricted internet access. Overall, I’m quite satisfied with the solution.

Reference: https://icloudnative.io/posts/custom-derp-servers/ ↩︎
Reference: https://tailscale.com/kb/1232/derp-servers ↩︎
About HuJSON: https://github.com/tailscale/hujson ↩︎
Reference: https://tailscale.com/kb/1408/quick-guide-exit-nodes ↩︎
Reference: https://tailscale.com/kb/1320/performance-best-practices#linux-optimizations-for-subnet-routers-and-exit-nodes ↩︎
UDP GRO (Generic Receive Offload) is a Linux kernel network optimisation that merges small packets to improve efficiency. However, when acting as a forwarding node, this can increase latency and reduce throughput under packet loss conditions. ↩︎
Compared to fake-ip, redir-host offers better compatibility, fewer issues, and avoids temporary disconnects caused by fake IP residue when toggling proxy modes. My Pi uses a preconfigured SmartDNS setup with no DNS pollution, resulting in a smooth experience. ↩︎
Reference: https://blog.zonowry.com/posts/clash_iptables_tproxy/ ↩︎
lo is the default loopback interface in Linux systems. In transparent proxy setups, it not only handles localhost traffic but is also used to receive network connections originally destined for external addresses, enabling local hijacking and forwarding of external traffic. ↩︎

Google Play Store's CDN in China: From Cryptography Basics to Traffic Routing Optimisation

Sat, 15 Mar 2025 21:15:01 +0800

After switching to my own Mihomo override rules, my phone kept spinning when downloading apps from Google Play, but using the rules from the VPN service worked fine, which was very strange. So, I checked the Mihomo kernel logs.

play-lh.googleusercontent.com:443 match RuleSet(cdn_domainset) using Static Resources[🇭🇰 Hong Kong 07]
play.googleapis.com:443 match GeoSite(GFW) using Node Selection[🇭🇰 Hong Kong 07]
play-lh.googleusercontent.com:443 match RuleSet(cdn_domainset) using Static Resources[🇭🇰 Hong Kong 07]
play-fe.googleapis.com:443 match GeoSite(GFW) using Node Selection[🇭🇰 Hong Kong 07]
services.googleapis.cn:443 match GeoSite(CN) using Direct Connection[DIRECT]

(The above logs have been simplified.)

The Google Play services pre-installed on Chinese smartphones use the domain services.googleapis.cn instead of services.googleapis.com, and this domain is set to direct connection in most traffic routing rules. Yes, that’s where the problem lies. Modifying the rules to route this domain through a proxy solves the issue!

…Or does it?

rr4---sn-j5o7dn7s.xn--ngstr-lra8j.com:443 match Match using Leakage[🇭🇰 Hong Kong 07]
rr2---sn-j5o7dn7s.xn--ngstr-lra8j.com:443 match Match using Leakage[🇭🇰 Hong Kong 07]
rr1---sn-j5o76n7z.xn--ngstr-lra8j.com:443 match Match using Leakage[🇭🇰 Hong Kong 07]

Wait, why do these strange domains appear every time I download an app from the Play Store? After some research online, a new world opened up.

Ångströ: The Opposite Yet Similar Counterpart to Google

Seeing xn--ngstr-lra8j.com, those familiar with domain names will know that this is PunyCode encoding, which decodes to ångströ.com. Anders Jonas Ångström was a Swedish physicist and a pioneer in spectroscopy.¹ The ångström (Å) is a unit of length named in his honour, where $ 1 Å = 10^{-10} m = \frac{1}{10} nm $. It is commonly used to describe very short distances, such as atomic and molecular sizes or the wavelength of light. It represents an extremely small scale, especially in physics and chemistry for fine measurements.

Although Google’s name is not directly derived from “Googol,” it was inspired by the term. “Googol” is a mathematical term representing $10^{100}$, a 1 followed by 100 zeros, an extremely large number often used to denote vast quantities in computer science.

In terms of naming philosophy, Google and Ångströ, two seemingly opposite technological concepts, exhibit a fascinating symmetry. The former originates from the creative adaptation of the mathematical term “Googol,” while the latter stems from the reimagining of the physical unit “Ångström.” These artistically transformed names resemble the double helix of technological civilization: Google embodies the ambition to navigate the vast digital universe, while Ångströ hints at the meticulous crafting of atomic-scale technological landscapes. When these creatively altered professional terms meet in Silicon Valley, they form a perfect cognitive coordinate system—pointing to the limits of human information processing while heralding the grand journey of technological civilization towards both the macro and micro scales.

Introduction to Cryptography: The Patterns of Google’s Infrastructure Domains²

OK, enough. Now let’s turn our attention back to Google’s infrastructure. First, let’s look at some complete connection domains:

rr4---sn-j5o7dn7s.xn--ngstr-lra8j.com
rr1---sn-j5o76n7z.xn--ngstr-lra8j.com
rr5---sn-i3b7knzs.xn--ngstr-lra8j.com

These seemingly random strings are actually the result of some simple cryptographic encryption. Let’s break down the core components.

City Name Conversion Rules

Taking rr1---sn-j5o76n7z as an example, the key information segment is the 8 characters after sn-: r1---sn-[123][45][6][78]. The first three characters, in this case j5o, represent the city name, derived from the IATA code of the city’s main airport through a cryptographic transformation.

First, construct a 5 * 7 alphanumeric table:

Row0: 1 0 2 3 4
Row1: 5 6 7 8 9
Row2: a b c d e
Row3: f g h i j
Row4: k l m n o
Row5: p q r s t
Row6: u v w x y

Rotate this table counterclockwise, starting from the bottom-left corner of the new table, and copy the data from the original table in the order “left to right, top to bottom” into the new table in the order “bottom to top, left to right.”

After rotation, we get the following table:

| 6 d k r y |
| --------- |
| 5 c j q x |
| 4 b i p w |
| 3 a h o v |
| 2 9 g n u |
| 0 8 f m t |
| --------- |
| 1 7 e l s |

The 5*5 section in the middle of the table, enclosed by lines, is the final cipher table, containing 25 characters representing letters a to y in order from left to right, top to bottom. For example, the IATA code for Shanghai Hongqiao International Airport is sha. We can use this table to get the encrypted ciphertext:

s is the 19th letter in the alphabet. Counting from left to right, top to bottom in the cipher table, the 19th character is n.
h is the 8th letter in the alphabet. Counting from left to right, top to bottom in the cipher table, the 8th character is i.
a is the 1st letter in the alphabet. Counting from left to right, top to bottom in the cipher table, the 1st character is 5.

The encrypted ciphertext is ni5.

Conversely, going back to the original city name j5o, we can reverse-engineer the plaintext from the cipher table:

j is the 3rd character in the cipher table, which corresponds to c.
5 is the 1st character in the cipher table, which corresponds to a.
o is the 14th letter in the alphabet, which corresponds to n.

The decrypted plaintext is can, which is the IATA code for Guangzhou Baiyun International Airport. Clearly, the server we connected to is located in Guangzhou.

What if Google had a server in Zurich, and Zurich Airport’s IATA code is zrh, which includes the letter z? Our cipher table only goes up to y. Don’t worry, Google has considered this issue—z corresponds to 1 in the cipher table.

Here’s the code representation of these rules:

table = "5cjqx4bipw3ahov29gnu08fmt1"
def iata2cipher(iata):
    global table
    iata = iata.upper()
    cipher = ""
    for element in iata:
        index = ord(element) - 65
        cipher += table[index]
    return cipher

def cipher2iata(cipher):
    global table
    cipher = cipher.lower()
    iata = ""
    for element in cipher:
        index = table.find(element)
        iata += chr(65 + index)
    return iata

# print(iata2cipher(input("IATA:")))
# print(cipher2iata(input("Cipher:")))

Server Group Number

The [45] and [78] positions, such as 76 and 7z, represent the server group (access point) number, composed of characters from the first column of the following table (separated by a line). The characters 7elsz6dkry represent 0123456789. Therefore, 76 translates to 05, and 7z translates to 04.

  | 1 2 3 4 5 6
7 | 8 9 a b c d
e | f g h i j k
l | m n o p q r
s | t u v w x y
z | 0 1 2 3 4 5
6 | 7 8 9 a b c
d | e f g h i j
k | l m n o p q
r | s t u v w x
y | z

Here’s the Python representation:

codeTable = "7elsz6dkry"
def cipher2code(cipher):
    global codeTable
    cipher = cipher.lower()
    codeString = ""
    for element in cipher:
        index = codeTable.find(element)
        codeString += chr(index + 48)
    return codeString

# print(cipher2code(input("Cipher:")))

Similarly, encrypting numbers into ciphertext follows the same logic, which we won’t elaborate on here.

Supported Protocols

The [6] position indicates network protocol information:

n: IPv6 (address range 0x000-0x3FF)
u: IPv6 (address range 0x400-0x7FF)
m: IPv4 only

For example:

a5mekn7r, IPv6 prefix: 2607:f8b0:4007:a::/64, IPv4 prefix: 74.125.103.0/24
a5m7zu7r, IPv6 prefix: 2607:f8b0:4007:407::/64, IPv4 prefix: 74.125.215.0/24
a5mekm76, IPv4 only, prefix: 208.117.242.0/24

Correct Traffic Routing

Understanding the cryptographic patterns of Google’s infrastructure domains allows us to implement more precise traffic routing strategies. Currently, it’s known that Google’s CDN nodes in China are mainly located in Beijing (2x3), Shanghai (ni5), and Guangzhou (j5o). The corresponding domain characteristics can be identified using regular expressions:

rules:
  - DOMAIN-REGEX,^r+[0-9]+(---|\.)sn-(2x3|ni5|j5o)\w{5}\.xn--ngstr-lra8j\.com$,DIRECT

This rule will match all domains like rr1---sn-j5o76n7z.xn--ngstr-lra8j.com that belong to domestic CDNs and mark them for direct connection. For other Google domains not covered (such as play.googleapis.com), the original proxy rules will still apply.

In fact, the upstream GeoSite database v2fly/domain-list-community has already optimised the rules for Google Play’s domestic CDN nodes³. Simply enabling the GEOSITE,GOOGLE-PLAY@CN rule in Mihomo’s configuration will automatically implement intelligent traffic routing for domestic CDN direct connections and overseas domain proxies:

rules:
  - GEOSITE,GOOGLE-PLAY@CN,Direct Connection
  - GEOSITE,GOOGLE,Proxy Selection

Reference: https://en.wikipedia.org/wiki/Anders_Jonas_%C3%85ngstr%C3%B6m ↩︎
Reference: https://github.com/lennylxx/ipv6-hosts/wiki/sn-domains ↩︎
Specific commit: https://github.com/v2fly/domain-list-community/pull/2436/commits/a86c1bf3d9bf577869180874d87c76ddf6282fc1 ↩︎