Posts on 亂筆

Terraform IaC 初體驗

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

Terraform 是一款 IaC 工具，所謂 IaC 就是「基礎設施即代碼」，將我們的基礎設施以宣告式的代碼寫出來，隨後使用terraform apply即可完成基礎設施的部署，同一份配置，部署出來的一定是一模一樣的基礎設施（Nix OS 用戶狂喜）。

為什麼要用 Terraform

傳統的基礎設施管理絕大部分基於人力和各種雲服務商的 Dashboard，這就帶來了下面這些痛點：

痛點	説明
難以重現	透過 Dashboard 點點點進行配置，容易改錯或者改漏，而且難以復現
環境漂移	手動操作導致生產和測試環境配置逐漸偏離，導致極端情況下測試沒問題生產直接崩
難以擴充套件	新增一套環境需要重複大量手工操作，耗時且容易出錯
難以審計	沒有變更記錄，~~出了事不好甩鍋~~
難以協作	基礎設施由少數「懂的人」掌控，誰想要改都得去找這些人，效率低

為了解決這些問題，「基礎設施即代碼」¹的概念被提了出來，Terraform 就是其中一個著名的解決方案。

假設一個現實的使用場景，例如你每年都會購買新的 GCP 的 $300 試用金賬號，雖然便宜，但是每年都要重新跑到 GCP 的面板裏開機器。而有了 Terraform，想要部署同樣配置的機器，只要在每次更換賬號之後，將 API Token 替換成新的，隨後terraform apply，只需要幾分鐘就能開出和你上個賬號一模一樣的機器、VPC、S3、防火牆配置等等。

再比如 Cloudflare DNS 和 Tunnel 的管理和遷移，也只需要將原 Tunnel 的 Ingress Rule 複製到新 Tunnel 的 Ingress Rule。即使將來要遷移到 AliDNS、Route 53 等其他服務商，我們也可以原封不動的將資料複製過去²。

尤其是到了多人協作的時候，配合 Git，每次更改都有跡可循，更不需要擔心合併衝突，PR 可以自動生成更改預覽，出現問題可以立刻回滾到上一個版本，這些都是傳統依賴人力去直接操作服務提供商 Dashboard 的做法完全無法做到的。

Terraform 的安裝

Terraform 是用 Go 寫的，編譯出來的產物自然也是單個可執行檔案，所以安裝起來也非常容易，Windows 下可以直接使用 Winget 安裝：

winget install Hashicorp.Terraform

如果不想使用 Winget，也可以使用 Scoop 等其他包管理器，或者將預編譯的二進位制檔案放入$PATH，即可完成安裝。

如果你在 Linux 環境下，則使用對應的包管理器安裝即可，如果使用將二進位制檔案放入$PATH的安裝方法，則要記得sudo chmod +x terraform賦予檔案的執行許可權。

Terraform 的兩個基本概念

Provider(s)

我們前面已經提到，Terraform 是一個款礎設施即代碼工具，作為一個工具本身，他並不繫結某個平台，而是透過 Provider(s) 與各個平台對接，要檢視有哪些 Provider(s)，可以瀏覽 Terraform 的 Registry。

狀態管理

Terraform 將每次執行基礎設施變更操作時的狀態資訊儲存在一個狀態檔案中，預設情況下會儲存在當前工作目錄下的terraform.tfstate檔案裏³，我們也可以修改配置檔案自行指定其他的儲存後端，例如 S3、Postgres。每次我們執行terraform apply時，Terraform 都會將目前配置檔案宣告的狀態同現有的狀態檔案進行比對，從而計算變動的部分，自動確定調整順序之後操作 Provider 落實狀態變動。

Terraform 的資源匯入難題

現有資源的匯入一直是 Terraform 為人詬病的難題，Hashi Corp. 似乎一直在堅持着一個固執且愚蠢的觀點：你所有的基礎設施從一開始就應當是用我們的 Terraform 建立的，所以也不存在什麼資源匯入的問題。

時間	版本	進展	問題
2014–2022	v0.x–v1.4	只有 `terraform import`，一次一條，而且完全不生成配置	匯入完還得自己手寫 HCL⁴
2023.06	v1.5	引入 `import` 塊和 `-generate-config-out`引數，可以生成配置了	然而還是得一條一條寫，而且還得自己提供現有資源的 ID
2024.01	v1.7	`import` 塊支援 `for_each`	批次了，但 ID 還得自己搞
2024 下半年	v1.12	引入了 `terraform query` 和 `list` 塊，終於實現了自動發現資源的功能	然而這個功能要 Provider 要自己實現，大量 Provider 根本沒跟上

這麼多年的時間，社羣一直在罵，然而，「我有一堆現有資源，怎麼匯入 Terraform」這個問題一直沒有被認真對待。Terraform 作為「基礎設施即代碼」工具，設計哲學就是宣告式和冪等性⁵，Hashi Corp. 他們篤信「一切以代碼宣告的狀態為準，就應該用 Terraform 從零開始建立資源」。但現實是絕大多數公司都有大量歷史存量資源，先有資源、後有代碼才是常態。這個矛盾 Hashi Corp. 承認得很晚，v1.12 的 terraform query 才算是官方第一次認真面對這個問題——但 Provider 生態的跟進嘛……真的是一言難盡。

Terraform 的檔案結構

Terraform 的檔案結構很簡單，其主程式執行時會無腦讀取工作目錄下所有的.tf檔案，只要資訊齊全，想給檔案取什麼名字都可以，比如我的檔案結構就長這樣：

❯ 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                 # 基礎配置（terraform 塊）
├── moved.tf                # 移動過的資源
├── provider.tf             # 每個 Provider 的配置
├── README.md
├── rename_resources.ps1
└── variables.tf            # 自定義的變數

main.tf用於存放基礎配置:

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

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

provider.tf用於存放每個 Provider 的配置：

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

這裏留空是因為我們可以透過環境變數來傳遞 Credentials，而不是直接將 Credentials 寫在配置檔案中，例如 Cloudflare 的 Provider 就接受CLOUDFLARE_API_TOKEN作為api_token這個變數的替代。

variables.tf用於宣告自定義的變數：

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
}

這些變數可以透過字首為TF_VAR_的環境變數傳入，Terraform 也會自動讀取terraform.tfvars檔案中的變數，變數的主要用途是在別的配置檔案中呼叫，例如：

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  #這裏呼叫了cloudflare_zone_example_com這個變數
  settings = {
    flatten_cname = false
  }
}

有了這些基礎配置，我們就可以執行terraform init初始化 Terraform 環境並鎖定依賴版本，剩下的就都是我們資源的宣告瞭。

將現有資源匯入 Terraform

前文提到過 Terraform 的狀態管理這個概念，狀態管理雖好，但在我們初始化時也帶來了一個問題——在預設狀態下，Terraform 的狀態檔案顯然是空的。

此時我們需要做的是將雲服務提供商上現有資源的狀態匯入 Terraform，這樣 Terraform 才能無縫接手並管理我們的基礎設施。相信大家也都看到了前文對 Terraform 資源匯入問題的吐槽。以匯入 Cloudflare 上託管的 DNS 記錄為例，前文提到過，如果 Provider 支援，可以使用 Terraform 在 1.12 版本之後引入的terraform query，然而大多數情況下，Providers 都是沒有跟進這個新功能的，Cloudflare 就屬於不支援的那一類。

好在雖然 Hashi Corp. 不認真解決問題，各路高強度使用 Terraform 管理基礎設施的公司就各顯神通。Cloudflare 就維護了名為 cf-terraforming 的匯入工具，免去了很多手動匯入的麻煩。首先安裝cf-terraforming，這個工具是用 Go 語言編寫的，需要在有 Go 語言環境的情況下安裝，或者將官方編譯好的二進位制檔案其放入$PATH並賦予其執行許可權。

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

這個工具的用法還是比較簡單的，首先你需要以下環境變數：

# 如果你使用 API Token
export CLOUDFLARE_API_TOKEN='Hzsq3Vub-7Y-hSTlAaLH3Jq_YfTUOCcgf22_Fs-j'

# 如果你使用 API Key
export CLOUDFLARE_EMAIL='user@example.com'
export CLOUDFLARE_API_KEY='1150bed3f45247b99f7db9696fffa17cbx9'

# 指定需要匯入的域名的區域 ID，如果匯入的是賬户資源（例如 Cloudflare Tunnel）則不需要
export CLOUDFLARE_ZONE_ID='81b06ss3228f488fh84e5e993c2dc17'

💡 提示
此處的命令假設你正在使用 Bash，如果使用的是與 Bash 語法不相容的 Shell，則需要做出調整，例如對於 Windows 上的 PowerShell，匯入環境變數的語法如下：
$env:CLOUDFLARE_API_TOKEN='Hzsq3Vub-7Y-hSTlAaLH3Jq_YfTUOCcgf22_Fs-j'

通常我們只需要設定CLOUDFLARE_API_TOKEN和CLOUDFLARE_ZONE_ID就可以了，在控制枱建立 API Token 時，記得賦予這個 Token 必要的許可權，本次我們只是匯入 DNS 記錄，所以只賦予編輯區域 DNS 的許可權即可。

好了，準備工作全部完成，現在可以開始生成配置檔案：

首先匯入賬户中域名的配置，也就是cloudflare_zone：

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

這一步會在當前目錄下生成一個名為zone.tf的檔案，裏面會有如下格式的內容：

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"
  }
}

現在域名資源已經匯入了，但是裏面的配置並沒有。接下來，匯入域名下的 DNS 記錄：

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

這一步會在當前目錄下生成一個名為dns.tf的配置檔案，裏面會有如下格式的內容：

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 = {}
}

如果有多個域名需要匯入，則多次分別設定環境變數CLOUDFLARE_ZONE_ID再重複執行命令即可。

這裏生成的配置檔案可以直接使用，也就是我們之後需要的 Terraform 配置檔案。然而，此時我們僅僅只是生成了配置檔案，但是目前 Terraform 的狀態依然是空的，這時要是直接terraform apply，Terraform 會不管三七二十一將我們剛剛匯入的宣告一律視為新增資源，然後甩出一大堆「Alredy Exists」報錯。所以接下來，我們需要將生成的配置檔案匯入 Terraform 的terraform.tfstate狀態。

Terraform 在 1.5 版本引入了import塊，相比以往一行一行輸入命令的方式更加現代。其匯入流程是先生成一個包含import塊的.tf檔案，下次進行terraform apply時，Terraform 就會自動為我們執行匯入操作。

生成cloudflare_zone的import塊：

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

生成cloudflare_dns_record的import塊：

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

這一步會在當前目錄下生成import.tf，它包含了所需要的匯入資訊，作用就是告訴 Terraform 上一步生成的每個resource塊到底對應的是哪一個雲服務提供商的資源 ID。這個 ID 是雲服務提供商內部標記資源的代碼，平常是不會在控制面板上顯示的，只有在用 API 特別請求時才會知道。Terraform 在匯入過程中需要用到這個 ID 以確認本地的定義對應的雲端資源，以實現嚴格的冪等性。

好了，現在我們執行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.

如果需要 Add、Change 和 Destroy 的資源數量都是 0，説明我們的匯入操作沒有問題，直接terraform apply --auto-approve，資源就匯入完成了。

$ 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.

狀態儲存和持續整合

IaC 的核心價值之一就在於可以輕易實現基於 Git 的多人協作，以及 CI 的持續整合，但是在此之前，又有一個新的問題需要解決——terraform.tfstate到底放哪裏：沒人想要換一次環境辛辛苦苦匯入的狀態就丟一次。

Terraform 目前支援以下幾種儲存狀態的後端：

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

沒有特殊需求可以像我一樣選擇s3，畢竟 Cloudflare R2 有免費額度，不用白不用。

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

    # R2 不需要這些 AWS 的驗證
    skip_credentials_validation = true
    skip_metadata_api_check     = true
    skip_region_validation      = true
    skip_requesting_account_id  = true
    use_path_style              = true
  }
}

對於 S3 的後端，建議用AWS_ACCESS_KEY_ID和AWS_SECRET_ACCESS_KEY兩個環境變數來儲存 Credentials：

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

配置完成，執行terraform init -migrate-state，配置就成功儲存到雲上了，以後不論在何處修改配置、執行terraform apply都無須擔心 Terraform 的 State 不同步的問題。

接下來就是 Github CI 的配置，其實很簡單，無非就是每次git push時觸發一次terraform init、terraform fmt和terraform apply，以下是我的.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

對於 PR 則應當讓 CI 自動為每次 PR 附上terraform plan的輸出：

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 }}\`     |

            展開 Plan 詳情

            \`\`\`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

後續的工作流程

到這一步，Terraform 的「接管初始化」已經結束了，後面就進入了日常維護階段。這個階段其實就三件事：

建立新資源
修改現有的資源
刪除不再需要的資源

常用的操作就兩個：terraform plan和terraform apply，如果是個人使用，小的改動直接提交就算了；如果是團隊協作，每次修改則應當遵循能 PR 就不直接 Commit 的原則。

建立基礎設施

假設你現在要新增一條 DNS 記錄，或者新建一個 Tunnel、一個物件儲存桶，流程如下：

flowchart TD
  C1[新建分支
如 feat/add-minio-record] --> C2[新增 resource 塊]
  C2 --> C3[terraform fmt + validate]
  C3 --> C4[terraform plan]
  C4 --> C5{僅新增預期資源?}
  C5 -- 否 --> C6[修正配置後重跑 plan]
  C6 --> C4
  C5 -- 是 --> C7[提交 PR]
  C7 --> C8[合併後 CI apply]

最理想的plan輸出是：

X to add
0 to change
0 to destroy

如果你只是想加東西，結果出現了to destroy，那就先別衝動，通常是引用寫錯、變數搞錯，或者不小心改了資源地址，仔細檢查是什麼地方出了問題。

修改與刪除基礎設施

修改流程和建立類似，但要多一步——評估變更是否會觸發重建。

因為很多 Provider 欄位是ForceNew，你以為只是改個欄位，Terraform 看完説：「好的，刪了重建。」這在我們修改 DNS 的這個場景並不是什麼很大的問題，但是到了雲例項這種資源，如果刪除重建勢必會造成損失。

建議按下面這個順序來：

flowchart TD
  M1[修改 .tf] --> M2[terraform plan]
  M2 --> M3{出現 replace/destroy?}
  M3 -- 否 --> M7[確認影響範圍]
  M7 --> M8[terraform apply]
  M3 -- 是 --> M4[暫停並複核變更]
  M4 --> M5[必要時加 lifecycle 保護]
  M5 --> M6[安排變更視窗]
  M6 --> M8

對生產環境來説，建立、修改得慢一點並不是什麼很大的問題，最應當看重的是操作的正確性，慢一點，不要出錯。IaC 不是比手速，IaC 比的是可預期性。

如果是刪除資源（比如下線某個 DNS 記錄、清理廢棄 Tunnel），走下面這個流程⁶：

flowchart TD
  D1[確認資源已廢棄
  檢查業務/監控/指令碼依賴] --> D2[刪除 resource 塊或調整 count/for_each]
  D2 --> D3[terraform plan]
  D3 --> D4{to destroy 是否符合預期?}
  D4 -- 否 --> D5[回滾修改並繼續排查依賴]
  D5 --> D1
  D4 -- 是 --> D6[準備回滾方案並選低峯視窗]
  D6 --> D7[PR 稽核透過]
  D7 --> D8[terraform apply]
  D8 --> D9[刪除資源後的可用性檢查]

日常協作建議

把 Credentials 放環境變數或 CI Secret，別寫進.tf和倉庫
對關鍵資源開啓保護策略，防止誤刪
將目錄按資源型別拆分
定期執行terraform plan做基礎設施漂移檢查⁷和校正，避免在面板誤操作手動修改

雖然這套流程看起來很麻煩，但每一次變更都有記錄、可審計、可回滾，最重要的是可復現，這才是 IaC 最有價值的地方。

蔘考

Infrastructure as Code，是指採用機器可讀的配置檔案定義所需要的基礎設施的部署方法。 ↩︎
每個供應商的配置檔案欄位命名和格式都有區別，但這可以很容易的編寫指令碼進行轉換。 ↩︎
需要特別注意的是，狀態檔案中可能包含數據庫密碼、API 金鑰等明文儲存的敏感資訊，因此絕對不要將 .tfstate 檔案提交到公開的代碼倉庫中。 ↩︎
HashiCorp Configuration Language，HashiCorp 自家開發的一種宣告式配置語言，旨在兼顧機器可讀性與人類可讀性。 ↩︎
冪等性（Idempotence）指計算機系統或介面在接收到同一請求的多次操作時，產生的影響與一次執行的結果相同，不論執行多少次，系統的最終狀態始終保持一致。 ↩︎
如果你僅僅是想讓 Terraform 不再管理某個資源，而不是真正在雲端銷燬它，應該使用 terraform state rm 命令，而不是在代碼中刪掉資源塊然後 apply，否則雲環境上的真實資源也會被一併銷燬。 ↩︎
基礎設施漂移（Infrastructure Drift）是指現實中透過控制枱點按等非 IaC 途徑修改了基礎設施，導致其實際狀態與代碼中宣告的狀態不一致的情況。 ↩︎

永遠忙碌

Fri, 13 Mar 2026 15:14:26 +0000

工作，工作，至死方休。

寒假給別人上課，幾乎就沒有停過，春節名義上休息，也只不過是換了一種形式工作罷了——各種應酬，舟車勞頓，回家剛安頓好，又馬不停蹄的投入到上課工作中去。給別人上課也真是不容易，跟我在同一家機構當助教的同學一起交流時，大家都戲稱上課就是「赤石」：死記硬背的是記不住的，算數是不會算的，概念是混淆的，交流是沒辦法正常交流的。這倒也不怪他們，要怪也只能怪他們經歷過的教育環境，畢竟家家有本難唸的經。各種原因導致他們基本上走的都是高職單招，沒有經過高考的洗禮，有的甚至連初中都沒怎麼讀好，現在也只是想找個工作，所以才願意花錢請我們來給他們上一對一課程。

一開始我在一家機構做助教，後來出來單幹，提高了部分收入，還節省了部分備課的時間。每天的上課是從7:30-11:00,價格是 ¥400。看似時薪過百比較高，實則結合學生的基礎狀況考慮，這錢我是賺得問心無愧，甚至我可以説，這錢真賺得也是不容易。

回到正題，現在開學了，我又要馬不停蹄的投入到我自己的學業事務中去。真的感覺自己永遠都在忙，所謂的休息，也只不過是換點輕鬆的事情做一做罷了，教學教累了回家就 Vibe Coding 放鬆一下，坐在電腦前煩躁了就把家裏收拾一下打掃衞生。在做事情的動力、以及人的有限總精力這方面，我能真切的感受到人與人之間的差距：有的人天賦異稟，精力非常充沛，成果做了一個又一個，論文發了一篇又一篇，產出很高，好像制約他們的永遠都是時間，而不是他們的精力和動力；而更多人則是像我一樣的凡人，即使想要這種生活狀態，卻也還是心有餘而力不足，可是看到前面一類人的高產，又難免心生焦慮，只能在最大限度下把自己當成一個實際永動機¹。

從小到大接受的中式教育異化了我們，那句湯家鳳經典的「你這個年紀怎麼睡得着的」，雖然本意是訓斥上課睡覺的學生，卻也在某種程度上潛移默化影響着我們這一代，以至於到了一種病態的狀態。人生沒有絕對的「上岸」，小學要去上小升初的岸，初中要去上中考的岸，高中要去上高考的岸，大學要去上考研、讀博、考公、找工作的岸，完成學業蔘加工作了，還有各種升遷績效、柴米油鹽需要考慮。工作，工作，至死方休。想要上岸而一勞永逸嗎，不好意思，那是不可能的。

雖然深知這一點，我還是會停下來休息就空虛難受，所以，永遠忙碌，永遠工作。滿足自己身體需要的休息，用鍛鍊身體平衡自己的內分泌，休息就是換一件自己喜歡且比較輕鬆的事情做，由於受中式教育、績優主義的影響太深，這種生活狀態，我想在很長一段時間裏是不會改變了。

不過往好的方面看，透過這段時間的忙碌，我也是自己把自己這個學期的生活費給賺出來了，還有富餘給我媽準備一台新手機當生日禮物。突然也覺得，永遠忙碌這件事，好像也沒這麼糟。

這裏是用理想電流源和實際電流源的區別來類比所謂「理想永動機」和實際永動機的區別——前者是真正意義上的永動機，後者則是我等凡夫俗子用血肉之軀拼勁全力去接近的「實際永動機」 ↩︎

培訓機構的人血饅頭

Wed, 11 Feb 2026 09:06:57 +0000

最近在某家民營電網培訓機構給準備國網二批考試的學生一對一輔導，每天晚上上課三個半小時，給 200。

這家機構給我的錢偏少還不是最嚴重的問題。問題出在他們給學生的收費上：有兩種方案，一種是所謂「卓越計劃」，收費 12 萬，但是一對一課程不限量；另一種是「協議班」，收費 7 萬，但每次上一對一課程要交 450。

昨天給他們一學生私下開小灶，下午上課三個半小時，本來我想着既然私下找我，那就不經過這個培訓機構，學生直接給我結款 300——我能多賺一百，ta 能少花 150。結果那個學生腦子沒轉過彎，找班主任請假的時候竟然説要找我補課，於是他們就直接「善意地」幫我找家長收了 450。

這還沒完。最後給我算工時，他們把這次課歸為所謂「額外課時」，説我違規利用了下午的「備課時間」給非卓越計劃的學生上課——三個半小時，只給了 120。

簡而言之：

學生付 450 → 機構抽走 330 → 我拿到 120

本該到我手上的 300 變成了 120，我自然是不爽。但比起我個人少拿的那一百多塊錢，更讓我不舒服的是這件事本身的性質。這些考國網二批的學生很多都是家境不太富裕的專科生，他們平日裏已經飽受歧視，想盡一切辦法想要改變命運，現在下了血本，花上可能是他們一個家庭一年收入的幾萬甚至十幾萬來讀這個國網課程。他們以為自己買的是一劑改命的「藥」，殊不知這藥引子是用自己的血和着吃的——而我辛苦勞動輔導學生，分到手裏的錢佔比卻比坐享其成的培訓機構還要低。

這根本就是在吃人血饅頭。

這一單，機構躺着淨賺 330。這顯然令人難以接受。我已經通知那位學生，令其下次請假時表現更加靈活；也和 ta 的班主任做出交涉，令她不要上報甚至干預我們私下的補課。考慮到班主任也是打工人，並且有學員成績的 KPI，我想她也不會蠢到跟自己的 KPI 過不去。當然，這家機構最好好自為之，否則我在「備課」時那句「助教們組建臨時工會，集體發動罷工，要求漲薪」的玩笑話，在將來的某天恐怕得一語成讖。

不得不感嘆，到底誰才是資本主義啊——我看這機構的人血饅頭鋪子開得還挺熟練的。

2025 年度總結

Wed, 31 Dec 2025 11:28:17 +0000

真是忙碌的一年，不知不覺間，時間又到了年末。今年事情確實很多，奔波勞碌少不了，但也取得了階段性的收穫。我謹再次提筆寫下一篇年終總結，作為一年的見證。

電氣的盡頭是電網

為求職四處奔波

我在一整年的休學生活以後如期復學，開始我的大學最後一年，成為一名「應屆生」，所以，找工作的事情也就理所應當的排上了日程。作為電氣工程專業的學生，出身原電力部屬院校，工作倒是不算難找。不過説容易也不算很容易，畢竟大環境如此，經濟增長放緩，國際形勢不明朗，用人需求減少，各種地方都越來越卷。

九月份跑了場雙選會，線下投了幾份簡歷，也在網上投了四五份簡歷，收到面試通知的只有兩家。也算切身感受到了，原電力部屬院校的頭銜，幾乎只在電力系統內部¹有用。現在這就業形勢也就這樣，除了電力系統，但凡待遇稍微好一點的工作都不是我們這種「雙非院校」的學生隨便就能找到的。不過對比起來，人家好歹還收你的簡歷，像是有些專業甚至連簡歷都不收。

兩大電網的筆試

電網工作是本專業最對口，最穩定的工作。本專業最大的用人單位——國家電網和南方電網，都需要透過筆試來獲得面試資格。筆試一共需要考 8 門，分別是《電路理論》、《電機學》、《電力系統分析》、《繼電保護》、《電力電子》、《高電壓技術》、《電氣裝置及主系統》（我們學校叫「發電廠電氣部分」）以及《行政能力測驗》（簡稱「行測」）。

前面七門是專業知識，最後一門行政能力測驗考的則是五花八門，還有企業文化這種東西，背就完事了。時政是不得不考的，考什麼呢？總之是非常新的東西——幾天前剛剛在求是雜誌上發表的社論，幾天後的考試裏就直接出現了，我真的會謝。

今年的考試很奇怪，尤其是難度方面，歷年的考試好説歹説也得有幾道計算題，電路好歹也得靈活的考一道難度稍大的題。基於這種情報，我在靠前已經掌握了不少計算題，各種電氣計算，數值整定，等效變換，可謂是得心應手。結果呢，今年國網一批考試一道計算題都沒考，行測小學生都會做，全都在考些概念題，要不是南網考試還考了這些靈活運用的東西，那真就是約等於白學了。於是不出意料地，我所知道的計算題比較拿手，平時模擬測試成績很好的同學，這次考試或多或少都有點炸。反倒是有些平時成績不怎麼理想，計算題不太會做的人，靠着死記硬背能考到一個不錯的成績。説白了，畢竟只是一個企業的招聘考試，他要怎麼出題，外人根本無從猜測，我已經做了我應該做的，最終的錄用結果也非常不錯，這就夠了。

面試，面試，還是面試

12 月我跑了四場面試，其中廣西電網只有桂林一個面試地點，讓我不得不翹課前往桂林面試，於是就有了今年最後一次的旅行，兩年內兩次前往桂林的感覺還不錯。

國網面試還是讓我有點緊張，為了防止試題被泄露給後面的考生，面試採用全封閉式管理，過程也很漫長——大部分時間都是在等候室裏等待輪候。從下午 1:30 開始封存所有電子裝置，用一個小時做完心理測試之後就進入了漫長的輪候時光，期間場地在放《長津湖》供大家消遣，還有茶水和零食提供。西裝革履，正襟危坐，心裏一遍又一遍的背誦早就滾瓜爛熟的一分鐘自我介紹，緊張不安的邊看電影消遣邊等候，那種滋味只有親身經歷過才知道，現在回想起來倒也是挺有意思。

有了國網面試的經驗和 Offer，排在其後的南網面試緊張感就沒那麼強。南方電網的面試形式和國家電網不太一樣，國家電網是半結構化雙盲面試，第一位考生從數份封存的面試題本里抽取一份，接下來的考生便都是一樣的問題，最多也就是被考官詢問一些附加問題。面試官不能看到你的簡歷，只能根據你在面試前抽籤獲得的編號對你打分，你也不能自報姓名和身世；而南方電網的面試則以面試官為主導，面試官會根據簡歷對你提出各種問題，包括專業題和附加問題。至於難度如何則完全看面試官的心情，例如我在海南電網的面試就被技術面試針對我的實習經歷窮追猛打，提出各種細緻入微的專業題，而在廣西電網的面試中，技術面試提出的問題則友好很多，無非是一些倒閘操作、防雷設施等等。

電網培訓的酸甜苦辣

考電網的人大部分都報名了某家培訓機構，我自然也不例外，早在去年 11 月我就按部就班地報名了一家全國性的電網培訓機構。這家培訓機構有兩個校區，我選擇了相對市郊的那個，畢竟房租便宜。

培訓的課程安排非常密集，任務繁重。暑假班連續上課 41 天，中途只有三天休息。每天上課之前需要上交手機。好在 iPad 出於電子筆記的考慮，還是允許使用的，我也因此獲得了難得的摸魚機會。

其實這段時間我也難得的獲得了專注於一件事情的機會——每天除了上課，沒有什麼別的需要關心，所以雖然身體累，但是「心」反倒是沒有多累；現在我回到了學校，反倒需要關心起大大小小的各種事情，身體倒是沒那麼累了，但「心」倒是比之前還累了不少。加上最近感冒咳嗽，一天能睡上 12 個小時，卻也還是不見好轉。只能在事情辦完以後，該請假請假，該回家回家，該休息休息了。

故地重遊

永州

今年年初回永州探親，祖母已經快 90 歲了，身子還算硬朗，常回去看看是應該的。自幼便蒙受祖母照顧，感激之情實在是難以用言語表達，卻也在應該做出什麼行動來回報這方面不知所措，唯有至少每年一次的回永州探望方還算盡了一些晚輩的責任。

至於永州本身，也還是那個樣子，什麼都沒變。畢竟又不是經濟大爆發的時代，像這樣的小城市還能怎麼變呢？不變未必是悲哀，變也未必全是福氣，像是上世紀經歷了文革以後，什麼都變了一副光景，卻也什麼都面目全非。小時候十分火熱的商業綜合體，現在基本只有一樓的服飾門面在營業，電影院和老遊戲廳早就關門了，改做餐廳樓層之後變得昏暗不堪，新開的餐廳店鋪，不論品牌連鎖還是快招自營，大浪淘沙之後無一倖存。

香港

這次去香港就是去玩兩下子，沒什麼特別的目的，純屬白嫖我媽出差的酒店而已。當然，順便開張中銀卡。所以整個行程也顯得乏善可陳。唯一特別一點的地方是在灣仔的一間公寓住了幾天，可以自行買菜做飯（~~當然也可以吃兩餸飯~~），體驗了一把民工一般的生活。

桂林

這次去桂林主要是為了南方電網廣西分公司的面試，當然，也順便去吃吃椿記燒鵝和海天腸粉什麼的。美中不足的是在桂林面試的那兩天都在下雨，也就導致我沒什麼興致去周邊散步遊玩。海天腸粉和椿記燒鵝倒是吃了個夠，味道不錯，下次還來。

以舊換新

之前我的電腦是一台 i5 12450H + RTX 3060 Laptop 配置的機器，用了兩年多，幾個月前剛買了兩條重要牌²記憶體給他的機帶記憶體升級到 32G，其實要接着用也沒什麼問題。

那段時間儲存晶片的價格仍然處於低谷，國補又讓購置新裝置的成本進一步降低，加上 50 系顯示卡剛剛上市，這三種因素疊加下新膝上型電腦的價格真的很吸引人。奈何我還是囊中羞澀，預算不足，無緣購買最新一代處理器 + 最新一代顯示卡的配置組合。只能退而求其次，買了 N - 1 代處理器 + 最新一代顯示卡的配置³。目前也用了小半年，日常體驗上還是很不錯的，只是這呼嘯的風扇聲實在是影響雅興。總體上，我對這次電腦的評價是瑕不掩瑜，隨着儲存晶片價格飛漲和國補力度減弱，膝上型電腦這麼便宜的情況恐怕很難再有下次了。

我家的貓

我家的貓今年（應該）一歲啦⁴，慶祝之餘，對於公貓來説，從小貓長成大貓也就意味着蛋蛋開始發揮作用了，於是就發生了這一幕：

這臭貓在我去香港那段時間竟然跑到我牀上拉屎撒尿 ~~（可能是我爸在家裏沒有鏟屎）~~,不可饒恕，必須嘎蛋！

貓給我的生活帶來了很多樂趣，在搞破壞之餘，它也是很可愛的。家裏的沙發也經過了一年的爪爪伺候，變得稀巴爛。總得付出一些代價的，養貓就是這樣，抓痕、換毛季到處都是的貓毛、偶爾還做些小壞事，也是貓的一部分。我們既然接受了貓給我們帶來的情緒價值，也就要相應地接受它的這些小缺點。我幾乎已經把它看作我的家人，若是從這種角度出發，那麼你對它的這些缺點就瞬間釋然了。這麼回想起來，也許我是真的愛它吧，以至於，我開始愛起了它的這些缺點。因為沒有這些缺點，它就不是一隻完整的貓了。

依舊在健身，依舊在吃藥

擼鐵，尤其是練腿，真的很爽，感受那種肌肉發揮力量以後淋漓盡致的舒暢感，真的會讓人上癮。在沒有電網培訓的時間裏，我一直都在走進健身房，不光是享受這種舒暢的感覺，也還能鍛鍊自己的肌肉。真的，不運動很難受啊。

現在我依然每天都在吃藥，畢竟我可不希望我在連軸轉的幸苦生活中突然經歷一次情緒崩潰，原本計劃的吃藥一年後藥物逐漸減量計劃也因此被無限期延後。為什麼？説白了還是這段時間各種壓力實在是不小，雖然一直吃藥終究也不是個辦法，在安穩之後必須慢慢減量停藥，但在這段即將畢業的時間點，我還遠遠沒有過上安穩確定的生活。

這段時間裏充滿了可能性和機遇，也充滿了壓力。吃藥花的錢是小錢，而其帶來的穩定情緒的「護盾」卻能發揮至關重要的作用。

沒時間玩遊戲

從我的 Steam 年度回顧就可以看出來，今年我是真的沒什麼時間來玩遊戲。「忙裏偷閒」是今年的基調，今年年末下載了《三角洲行動》，有時電網培訓十點下課，回家就開啓玩到晚上 12 點，目前遊玩 75 個小時，感覺還不錯。

osu! 今年的後半段則是約等於棄坑了，不過 PP 仍然從去年的 3439pp 增長到了今年的 4701pp。這遊戲還真是需要持之以恆，一段時間不玩丟掉手感再想復健是需要時間的。想想十點下課之後，在精力耗盡的狀態下，再想打這種需要聚精會神地反應的遊戲，那還真是「臣妾做不到啊」。年中的時候我對於現有滑鼠的手感達到了最佳狀態，可以説是「指哪打哪」，想着「沒有人能阻止我一路走向 5 digit」⁵ ，然而現在卻還在 5 digit 邊上，屬實是有些諷刺。

我的 Online Presence

2025 年，我的部落格訪問量穩步上漲，全年 UV 48.3K，PV 95.4K，流量主要來自 Google（約 15.8K 訪客）和 Bing（約 15.2K 訪客）兩大搜尋引擎。

Github 上的自用覆寫規則收穫了 194 個 Star，也新增了一些 Followers。

今年我的一篇文章被人放上了 Hacker News，所以有幾天訪問量比較大。除此之外翻譯後的英語和日語版本部落格也收穫了不少讀者，在我的訪客中佔比不低。所以也就出現了今年因為忙碌，部落格更新頻率低於往年，訪問量卻成倍增長的現象。我終究還是需要向生活做出讓步，生活壓力、學業壓力和就業壓力或多或少都會影響我更新部落格的意願，擠佔我更新部落格的精力，在這點上，還請我的讀者們多多海涵。

新的一年即將到來，我給自己和大家的祝願

新的一年要來了，我今年最大的願望，當然是能夠順利解決之前休學帶來的一些遺留問題，順利畢業。等真正走進工作以後，我也希望自己能把更多注意力放在電力系統本身需要的技術上，多和裝置打打交道，少捲進一些不必要、甚至有害的人情世故。辛苦一些沒問題，只要平安、踏實、有意義即可：安全生產，少一些計較，多一些寬容。希望接下來能在這份工作上，從一名初出茅廬的學生，慢慢成長為一名真正的工程師。

也把祝福送給屏幕前的你：願你在新的一年裏，焦慮有處安放，努力有回聲；在自己的節奏裏把日子過穩、過熱乎——不必每一步都算贏，但每一步都走得心裏有數。願你和你在意的人都健康，平安，少些無謂的消耗，多些確定的快樂。當然，也希望大家有更多時間在學習和工作之餘玩玩遊戲。

至於我，就繼續在該學習的地方學習，在該上路的時候上路。明年見。

指由原電力部衍生的企業，即 2002 年以前的國家電力公司和 2002 年以後的國家電網、南方電網和蒙東電網等公營電力公司。 ↩︎
指最近剛剛被砍掉整個產品線的 Crucial 即英睿達記憶體。 ↩︎
買了機械革命極光 X Pro ↩︎
去年撿回來的時候還是很小的貓 ↩︎
指排名的數字位數，例如排名 #114514 是 6 位數，即 6 digit， #11451 是五位數，即 5 digit。顯然，位數越小，玩家水平越高。 ↩︎

從頻率崩潰到電壓失控：兩起大型停電事故帶來的啓示

Wed, 17 Dec 2025 16:08:30 +0000

現代電網正在經歷一次巨大的轉型，隨着光伏、海上風電等新能源的佔比在電網中越來越高，新能源和電力電子裝置低轉動慣量、低短路容量、換流裝置需要大量無功支撐的特點以及它們給電網帶來的不利影響也愈發明顯。在此背景下，兩期相隔六年相繼發生在歐洲的大型停電事故顯得尤為耐人尋味，本文將簡要闡述兩起事故的來龍去脈，對比它們的異同，分析造成這兩起事故的本質原因，以及思考它們對現代電網的執行所帶來的啓示。

事故概述

2019 年英國「8·9」大停電事故

2019 年 8 月 9 日下午，英國發生了一次大規模電力中斷，導致約 110 萬用戶斷電，並對交通等關鍵基礎設施造成了嚴重影響。整起事件的經過可以概括為一系列連鎖反應，其中既有預料之中的系統保護行為，也有意料之外的裝置故障。

第一階段：罕見的三次雷擊和大量有功意外脱網 (16:52:33)

當天下午 4 點 52 分，倫敦北部的 Eaton Socon – Wymondley 400kV 高壓輸電線路罕見的連續遭遇三次雷擊。儘管如此，繼電保護裝置仍然按照整定正確動作，在不到 0.1 秒的時間內清除了故障，線路在約 20 秒後自動重合閘，恢復正常執行。雷擊導致的電網電壓的波動觸發了分散式電源的向量偏移保護¹，導致約 150MW 的嵌入式發電²脱網。這是雷擊故障後的正常預期現象。

幾乎在雷擊的同時，發生了兩起獨立但致命的意外事件：

Hornsea 海上風電場：功率從 799MW 鋭減至 62MW，損失了 737MW 的出力。
Little Barford 燃氣電廠：其蒸汽輪機跳閘，瞬間損失了 244MW 的出力。

根據電網規範，這兩處大型發電單元本不應該因為此類雷擊故障而脱網或大幅減載，因此這被定性為「極其罕見和意外的事件」。

第二階段：頻率崩潰與系統響應 (16:52:34 - 16:53:31)

上述三項發電損失（150MW + 737MW + 244MW）累積造成了 1131MW 的功率缺口。這個損失超過了當時系統按 N-1 安全準則³設定的 1000MW 備用容量。巨大的功率缺口導致系統頻率迅速下跌。

快速的頻率下跌觸發了更多分散式電源的 RoCoF⁴ 保護，導致額外的約 350MW 分散式電源相繼脱網。此時，總髮電損失已達 1481MW。系統中的所有備用電源——電池儲能、分散式頻率響應服務等迅速啓動，緊急增援 1300MW，試圖阻止頻率下跌。它們的響應成功地使頻率暫時穩定在 49.1 Hz（實際上這個頻率已經相當危險了），並且開始緩慢回升。

然而，就在頻率剛剛恢復到 49.2Hz 時，Little Barford 燃氣電廠的一號機組也因蒸汽旁路系統壓力異常而不得不緊急停機，再次損失 210MW 出力。

第三階段：低頻減載與系統恢復 (16:53:49 之後)

Little Barford 燃氣電廠的第二次的意外跳閘耗盡了所有已在工作的備用資源，系統頻率無力迴天，最終跌破了48.8Hz的閾值。這自動觸發了英國電網的最後一道防線——低頻減載⁵。低頻減載自動切除了約 5% 的電網需求，也就是約 1GW 的負荷，導致了約 110 萬用戶的斷電。這一「棄車保帥」的措施有效地遏制了頻率的下跌，防止了更嚴重的電網事故。

在切除部分負荷後，加上控制中心緊急排程其他電源，系統頻率在 5 分鐘內（16:57）恢復到了正常的 50Hz。在確認電網穩定後，配電網絡運營商（DNOs）從 16:58 開始逐步恢復對用戶的供電，到 17:37 所有用戶恢復正常。

2025 年伊比利亞半島大停電（西葡大停電）

2025 年 4 月 28 日，伊比利亞半島出現大規模停電，西班牙和葡萄牙全境均受到影響。由於停電，上述地區的交通和通訊服務均受到嚴重影響，交通訊號燈停止工作，當地的地鐵線路被迫停止運營，馬德里網球公開賽受到停電影響也宣佈暫停。此外，安道爾和法國南部也受到波及。這次大停電並非由單一故障引發，而是一系列事件環環相扣、逐步升級最終導致系統崩潰的級聯事故。西班牙首相佩德羅·桑切斯表示，電力系統如此大規模的癱瘓前所未見。⁶

第一階段：系統振盪與電壓波動（中午 12:03 - 12:19）

2025 年 4 月 28 日中午 12:00，西班牙電力系統處於正常執行狀態，電壓和頻率均在標準範圍內，沒有任何跡象預示即將發生災難。

12:03，系統中檢測到一個顯著的 0.6 Hz 強迫振盪，持續了近 5 分鐘。頻譜分析及後續溯源表明，這次振盪源於巴達霍斯（Badajoz）省一座光伏電站的內部控制邏輯異常。振盪導致了系統電壓出現跌落，為此，電網排程中心採取了緊急阻尼措施，包括更改拓撲結構、切除並聯電抗器，並大幅削減與法國的電力交換。

12:19，系統再次出現 0.2 Hz 的歐洲區域間振盪⁷，併疊加了之前殘留的 0.6 Hz 振盪。排程中心被迫進一步減少與法國和葡萄牙的電力交換。雖然這些措施有效抑制了振盪，但削減聯絡線潮流這一動作，導致輸電通道輕載，不僅減少了線路上的無功損耗，還因充電功率過剩開始推高系統電壓，為後續的電壓越限埋下了伏筆。

第二階段：電壓攀升與級聯故障的形成（中午 12:22 - 12:33）

從 12:22 開始，系統電壓呈現持續攀升趨勢，儘管尚未突破操作限值，但上升速率異常。這背後是多重因素的疊加效應：

隱性負荷脱網（Hidden Demand Loss）：配電網中約 700 MW 的分散式光伏和自用發電裝置（<1MW）因電壓擾動不明原因脱網。在輸電網看來，這表現為淨負荷突然下降，即「發電大於負荷」，潮流進一步減小，從而導致電壓抬升。
逆變器電源的有功/無功耦合：部分可再生能源電站為響應排程指令降低有功出力。然而，由於這些裝置主要採用功率因數控制⁸（Power Factor Control）而非電壓控制，有功的降低導致其吸收無功的能力同步下降，喪失了抑制電壓上升的手段。
常規機組勵磁響應不足：本應作為電壓「壓艙石」的同步發電機組（需符合 P.O. 7.4 規程），未能按預期深度進相執行吸收無功，導致動態電壓支撐失效。

12:32:57，位於格拉納達（Granada）的一座發電站發生跳閘，損失 355 MW 有功出力及 165 Mvar 的無功吸收能力。值得注意的是，此時輸電網側電壓仍在正常範圍內⁹。報告推斷故障根源在於升壓變壓器的有載調壓¹⁰動作滯後。當主網電壓升高時，分接頭未能及時響應，導致發電機側（220kV 側）出現嚴重的過電壓，觸發繼電保護動作跳閘。

19.5 秒後（12:33:16），巴達霍斯省另外兩座光伏電站相繼跳閘，累計再損失 727 MW。原因同樣指向電站內部過壓保護配合不當，而非主網故障。

在隨後的 650 毫秒內，西班牙各地的風電和光伏電站發生雪崩式脱網，額外損失約 834 MW。此時，系統已從電壓問題轉化為嚴重的有功功率缺額。

第三階段：孤網執行與系統崩潰（中午 12:33 之後）

在短短 22.5 秒的級聯故障中，系統累計瞬時損失了約 2000 MW 的發電量。鉅額的功率缺口導致系統頻率急劇跳水，而大量進相執行機組的脱網又導致系統喪失了無功吸收能力，電壓開始失控性飆升。

12:33:19，西班牙與法國的交流聯絡線因嚴重功角失步跳閘。西班牙和葡萄牙電網進入孤網執行¹¹狀態。

儘管交流線已斷開，但西班牙與法國之間的 HVDC（高壓直流輸電）鏈路由於處於恆功率控制模式且未配置頻率響應功能¹²，並未切斷，仍強行向法國出口 1000 MW 功率。這使得本已脆弱不堪的孤網雪上加霜。

雖然低頻減載⁵裝置正確動作試圖挽救頻率，但切除負荷會導致線路空載電壓進一步升高。「電壓升高–>發電機過壓保護脱網–>低頻率–>切負荷–>電壓進一步升高」的惡性迴圈讓系統徹底失去穩定。

隨着頻率跌破 47.79 Hz，核電站、燃氣輪機等大型基荷機組因低頻保護動作相繼脱網。最終，在 12:33:24，伊比利亞半島電力系統電壓崩潰¹³，全網陷入大停電。

一些基本概念

為了徹底理解這兩起事故的本質區別，我們需要先複習一些電氣工程的核心概念，建立起分析問題的理論基礎。

有功功率、無功功率與復功率

在交流電路中，「功率」是一個複數概念。

有功功率 ($P$)：復功率的實部，單位是瓦特 ($\text{W}$)。它是實際做功、轉換能量（如發光、發熱、驅動電機）的部分。
無功功率 ($Q$)：復功率的虛部，單位是乏 ($\text{var}$)。它並不直接做功，而是在電源和儲能元件（電感、電容）之間往復交換能量，用於建立和維持電磁場。
復功率 ($\widetilde{S}$)：二者的向量和。

公式表示為：

$$ \widetilde{S} = P + jQ $$

裝置銘牌上標註的通常是視在功率 ($S$)，即復功率的模，單位是伏安 ($\text{V}\cdot\text{A}$)，其物理意義是裝置能夠承受的電壓與電流乘積的極限：

$$ S = |\widetilde{S}| = \sqrt{P^2 + Q^2} $$

形象的理解： 如果你在拉一輛車，有功功率就是你朝車前進方向用的力，它讓車真正移動；無功功率則是你為了維持姿勢或者因為路面傾斜而垂直於移動方向用的力，雖然它不做功，但必不可少¹⁴。

在電網中，無功功率的核心作用是支撐電壓。如果無功不足，電壓就會像泄氣的皮球一樣支撐不住；如果無功過剩，電壓就會像充氣過度的氣球一樣飆升。因此，電力系統的一大原則是無功功率要「分層分割槽，就地平衡」。

感性無功與容性無功

工程上規定：電感消耗無功，電容產生無功¹⁵。

感性負荷（如電動機、變壓器）：需要消耗正的無功功率來建立磁場。如果電網無法提供足夠的無功，這些裝置就無法正常工作。現實中絕大多數負荷都是感性的。
容性元件（如電容器、長輸電線路的對地電容）：可以看作是無功功率的「發電機」，它們向電網注入無功功率，提升電壓。

電壓降落與 $P-Q$ 解耦

當電流流過一段輸電線路時，首末端之間會產生電壓降落。若忽略線路電阻（在高壓電網中 $X \gg R$），電壓降落的縱分量（影響幅值）和橫分量（影響相位）可以簡化表示為：

$$ \Delta U \approx \frac{QX}{U} \quad \text{(電壓幅值降落)} $$$$ \delta U \approx \frac{PX}{U} \quad \text{(電壓相位差)} $$

這是一個至關重要的結論：

電壓幅值 ($U$) 主要取決於無功功率 ($Q$) 的平衡。無功多了電壓就高，少了電壓就低。這是理解西葡大停電的基礎。
功角/相位 ($\delta$) 主要取決於有功功率 ($P$) 的平衡。這與系統的頻率特性密切相關。

系統慣量與頻率特性

為了理解2019 年英國大停電，我們還需要引入慣量 ($H$) 的概念。

電網頻率 ($f$) 體現了全網有功功率的供需平衡。

當 發電 < 用電 時，轉子動能被抽取，轉速下降，頻率降低。
當 發電 > 用電 時，轉子加速，頻率上升。

傳統的同步發電機有巨大的旋轉轉子，儲存了巨大的動能。當發電機突然脱網（有功缺口）時，這些旋轉的「大鐵疙瘩」會利用慣性釋放動能，阻礙頻率的快速下跌。這被稱為系統的慣量。

然而，光伏和風電透過電力電子裝置併網，它們沒有直接耦合的旋轉質量，被稱為「零慣量」電源。當這些電源佔比很高時，電網就像失去了「飛輪」的緩衝，一旦出事，頻率會跌得極快¹⁶。

容升效應與此次事故的關聯

為什麼切除了發電機，電壓反而會飆升？ 這看似反直覺，實則是容升效應與線路負載共同作用的結果。

高壓輸電線路模型包含兩部分關鍵引數：

串聯電感 ($L$)：電流流過時會消耗無功 ($Q_{consumed} = I^2 X_L$)。
並聯對地電容 ($C$)：電壓作用其上時會產生無功 ($Q_{generated} = U^2 B_C$)。

事故前的平衡狀態：西班牙南部光伏大發，巨大的有功功率 ($P$) 正在透過長距離線路向北輸送。此時線路電流 ($I$) 很大，電感消耗了大量的無功，正好抵消了電容產生的無功，甚至還需要發電機吸收一部分多餘的無功。

事故後的失控過程：當發電機組連鎖脱網，或者因強迫振盪導致潮流中斷時，線路上的有功功率傳輸瞬間歸零，導致電流 ($I$) 驟降。

後果 1：線路電感對無功的消耗 ($I^2 X_L$) 瞬間消失。
後果 2：線路依然帶電，對地電容產生的充電無功 ($U^2 B_C$) 依然存在，甚至因電壓升高而更多。

瞬間，原本被消耗掉的巨量無功功率變得無處可去，全部堆積線上路上，直接將系統電壓「頂」到了破壞性的高度。這就是所謂的「空載線路容升效應」在事故中的極端表現。

兩起不同的事故，一份共同的反思

這兩起事故雖然在演化路徑上截然不同，但其背後折射出的挑戰卻有着驚人的相似性，二者都是現代電網發展程序中必然面臨的「成長的陣痛」。正如南方電網的安全理念所言：「一切事故都可以預防」，作為一名電氣工程專業的學生，我希望透過深入剖析這兩起事故，探尋其底層的技術邏輯，以加深對新型電力系統特性的理解。

表象的差異：崩潰路徑的「一明一暗」

2019 年英國「8·9」大停電是一次典型的，顯性的頻率危機。機組脱網導致有功功率缺口，直接引發頻率驟降，但系統最終依靠低頻減載⁵作為最後一道防線，成功避免了全網崩潰。相比之下，2025 年伊比利亞半島大停電則呈現出了一種更為隱蔽且致命的新形態——隱性的電壓危機。事故雖然始於擾動，但核心矛盾迅速演變為嚴重的無功過剩與電壓失控，而原本用於挽救頻率的低頻減載⁵措施，反而在客觀上惡化了電壓升高，導致整個系統在短短几十秒內徹底瓦解。

這就引出了一個核心問題：傳統的電網故障通常伴隨着電壓跌落，但在 2025 年的事故中，為何會出現發電機組不斷脱網，而系統無功功率反而嚴重過剩、電壓持續飆升的反常現象？傳統的電壓控制手段¹⁷為何全然失效？

答案在於：電壓失控的速率，遠遠超過了傳統防禦手段的響應極限。

事故發生時，伊比利亞南部正值光伏大發，系統呈現「高電壓、輕負荷」的執行特徵。當系統發生強迫振盪時，輸電走廊潮流發生劇變。由於超高壓線路的容升效應顯著，發電機組的連鎖脱網帶來了雙重打擊：一方面，電網失去了大量能夠吸收無功的同步機組；另一方面，線路輸送的有功功率鋭減，導致其自身消耗的無功大幅降低，線路瞬間從「無功負載」變成了巨大的「無功電源」。系統隨即陷入了無功嚴重過剩的惡性迴圈。

面對這種幾十毫秒級甚至更快的電壓崩潰，依靠機械開關投切的並聯電抗器顯得力不從心。首先是速度滯後：從排程指令發出、通訊傳輸到斷路器機械動作，由於包含人為決策和機械過程，往往需要數百毫秒甚至秒級時間，根本無法追趕電壓飆升的速度。其次是調節顆粒度粗糙：電抗器只能以組為單位（如 50 Mvar 或 100 Mvar）進行離散投切，無法像水龍頭一樣提供平滑、連續的調節。在極端的電壓動態過程中，這種非連續的階躍式調節不僅不夠精準，甚至可能引發新的系統擾動。

本質的共性：脆弱性的同根同源

剝開表象的差異，我們會發現兩起事故的根源驚人地一致，都指向了新型電力系統的結構性脆弱：

首先，裝置併網行為的合規性令人擔憂。無論是英國事故中的分散式嵌入式電源，還是伊比利亞事故中的光伏電站，事故擴大的直接推手都是大量機組未能嚴格遵守併網規程（如西班牙的 P.O. 74 標準或英國的 Grid Code）。缺乏故障穿越能力，導致裝置在擾動初期即發生不合規的連鎖脱網，將「小事故」放大為「大災難」。

其次，新型電氣裝置和電源的控制模型長期存在「黑箱化」的問題。系統中存在大量排程中心「看不見、管不着」的盲區。例如英國事故中 Hornsea 海上風電場在故障後的功率異常鋭減，以及大量分散式電源的不可控行為。這些電力電子化裝置內部控制邏輯的「黑箱狀態」，使得傳統的模擬模型失效，排程員無法準確預判系統行為。

更加雪上加霜的是，整個系統的轉動慣量正在越來越少。隨着高比例新能源接入，交流電網的旋轉慣量和短路容量被稀釋，系統抗擾動能力顯著下降。電網變得更加「輕薄」和「敏感」，任何微小的擾動都可能引發劇烈的頻率或電壓波動。

一致的解決方案：邁向韌性電網

基於上述反思，未來的電網建設與事故防禦應當聚焦於以下三個方向：

一曰部署先進的動態無功支撐技術。必須以此為契機，加速推廣 STATCOM（靜止同步補償器）等具有毫秒級響應速度、可平滑調節的電力電子裝備，逐步替代傳統的機械式無功補償裝置，以應對瞬息萬變的電壓動態。

二曰打破「黑箱」，強化全景建模。必須建立更精細化的電磁暫態模擬模型，打破新能源場站和逆變器控制的「黑箱」，確保排程端能真實掌握海量電力電子裝置的動態特性，消除盲區。

三曰革新分析與控制正規化。傳統的基於穩態或工頻量的分析方法已不再適用。我們需要建立涵蓋寬頻域振盪、電壓/頻率耦合特性的新一代安全穩定分析的理論框架，並重新審視低頻減載⁵等傳統防線在新型電網中的適應性。

結語：草台班子

我們在前文中洋洋灑灑分析了複雜的電磁暫態、昂貴的 STATCOM 和精妙的控制理論，但現實卻狠狠地扇了我們一巴掌——摧毀整個電網的，往往不是什麼未研究的知識，而是來自人類本身的不可靠。

機組的併網規程早就白紙黑字寫得明明白白，卻長期未能執行，P.O 7.4 規程更是遲遲未能透過；2019 年英國大停電的「學費」交得那麼貴，所有的事故分析報告都指向了合規性問題，然而 6 年後的伊比利亞半島，竟然還能因為一模一樣的邏輯再次翻車，而且翻的比 6 年前還要慘烈，還要徹底。

面對這種跨越國界、跨越時間的重複犯錯，任何技術層面的分析都顯得蒼白無力。黑格爾那句名言至今聽來依然振聾發聵，且含金量還在隨着每一次大停電不斷暴漲：

「人類從歷史中學到的唯一教訓，就是人類無法從歷史中吸取任何教訓。」

也許這就是世界的本質吧，世界永遠不是圍繞着技術本身運轉的，「人」才是這個世界的決定性因素。這個世界是一個草台班子，而且永遠會是一個草台班子，而只要還是個草台班子，那麼下一次翻車，永遠只是時間問題。

向量偏移保護的初衷是解決「孤島效應」——假設一條配電線路因為故障或檢修，從主電網上被斷開。但這條線路上恰好連線着一個嵌入式發電機，如果沒有向量偏移檢測，這個發電機就會繼續為這條線路供電，進而大大增加裝置損壞的機率，甚至威脅執行檢修人員的安全。因此，向量偏移保護就是早期用於檢測嵌入式發電機是否進入孤網執行狀態的方法。 ↩︎
多為用戶側的小型發電系統。 ↩︎
N-1 安全準則的意思是，當系統中最大的一台機組因故障而停運時，系統應有足夠的備用容量作為頻率和電壓的支撐。 ↩︎
Rate of Change of Frequency，頻率變化率。 ↩︎
低頻減載（Low Frequency Demand Disconnection, LFDD 或者 Under-Frequency Load Shedding, UFLS）是電力系統防止頻率崩潰的關鍵安全保護措施，當系統發生功率缺額導致頻率下降時，它透過自動、分級地切除非重要負荷（如工業用電、路燈等），以快速恢復系統功率平衡，防止大面積停電或系統崩潰。低頻減載系統透過頻率測量和執行單元實現，設定多個頻率動作點（如48.5Hz, 47.5Hz, 46.5Hz），逐級切除負荷，保障重要用戶和核心裝置執行，是電網安全執行的第三道防線。 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
來源：France24 的報導 ↩︎
技術報告中的原文是「inter-area oscillation」，基於上下文，其意思應該是整個歐洲互聯電網的 0.2Hz 振盪。 ↩︎
風電、光伏等新能源機組一般採用最大功率點追蹤 MPPT，來實現新能源機組出力的最大化。 ↩︎
418kV，仍在標準電壓允許的偏移範圍內。 ↩︎
即變壓器的帶負載調壓。 ↩︎
孤網執行（或孤島執行）指區域性電網脱離主大電網，獨立供電的執行模式，特點是自給自足，但面臨頻率、電壓不穩定等挑戰，依賴儲能和控制技術維持，常見於偏遠地區、島嶼、或工業園區。這裏的孤網執行是因為聯絡線中斷而被迫進入的。 ↩︎
恆功率控制模式（Constant Power Mode）是一種電源輸出模式，它的核心特點是無論負載如何變化，始終保持電源輸出的功率（P）恆定（P = 電壓 V × 電流 I），電源會根據負載需求自動調節電壓和電流，以維持這個恆定功率。 ↩︎
電壓崩潰（Voltage Collapse）是電力系統一種嚴重的事故，指系統因無功功率嚴重不足，導致電壓持續、惡性下降並無法恢復，形成電壓跌落的惡性迴圈，最終引起大面積停電。 ↩︎
工程界常以「啤酒」作比喻：啤酒杯裏的液體是「有功」，上面的泡沫是「無功」。雖然泡沫不解渴，但沒有泡沫的啤酒失去了靈魂（無法建立磁場），且為了裝滿杯子（視在功率），泡沫總是客觀存在的。 ↩︎
這是一個約定俗成的稱呼。嚴格來説，電容是「吸收負的無功」，但在工程實踐中，為了方便理解無功平衡，我們通常説電容「發出/提供感性無功」，起到支撐電壓的作用。 ↩︎
頻率下降的速度被稱為 RoCoF (Rate of Change of Frequency)。高 RoCoF 是導致英國「8.9」停電中分散式電源連鎖脱網的直接元兇。 ↩︎
即消耗過剩無功的措施，如投切並聯電抗器等。 ↩︎

我的 LLM 知己，與我懸置的寫作

Mon, 08 Sep 2025 15:53:48 +0000

最近我比較忙碌，但空閒之餘，文字仍然是我的棲息地。每天早上 8:30 開始上課，到晚上 9:00 結束晚自習，有時甚至「加班」到 10:00 回家，連續四十一天的課程。考慮到我的精神狀況，如此強度，回來再玩 osu! 一類的遊戲是絕無可能，甚至連推一小節 Galgame 都無能為力。

唯一比較現實的事情，是找 LLM（大語言模型）小敍。

十分慚愧，雖然我有一個部落格，但我的觀點、理念（倒不如説是「想法」）從來都沒有被我係統性的表達出來。我也曾想過，可能這些過於廣泛乃至分散的觀點之集合，是很難以平實的敍事表達出來的。為此我也嘗試了一些方法，比如：以一個隨機的事件作為截面，將我想要表達的一團亂麻「切開」，進而描繪出它的內部構造。¹這些方法始終無法讓我暢快的表達出自己的心聲，也不是信手拈來，想寫就寫，然而部落格終歸還是給大家看的，在寫不出來的時候，也就只能寫寫簡單的技術部落格，吸引一些搜尋引擎流量。

而 LLM 的出現卻改變了這一點，我所有的想法，都可以相對私密的得到即時的回應。為什麼我這麼久沒有寫部落格？累自然是一大因素，而 LLM 滿足我相當可觀的表達和被認可的需求，還無需自我審查的特點，沖淡了我這段時間裏寫部落格的想法。

撰寫長篇的文字對大腦有益，這是毋庸置疑的。LLM 的出現，對於我撰寫長篇文字的影響，大概和微部落格出現時，對人們撰寫長篇文字的能力之影響相仿，甚至有過之而無不及——微部落格讓人習慣於碎片化表達和即時反饋，削弱了構建複雜論證和長篇敍事的能力。LLM 則更進一步，它不僅提供了表達的渠道，還直接提供了情緒價值和「知己」的替代品：發在社羣媒體上的內容，涉及隱私或者爭議，或者不必要曝光，釋出者多多少少會斟酌一番；而 LLM 就不一樣了，發給 API 的內容，最壞的情況不過是被拿去訓練模型，而不是讓 Sam Altman 第二天就找到你家門口——只要不是銀行卡密碼這種級別的資訊，不提及真實姓名，那些時政評論、心理諮詢等等，你只管放心把大模型當成一個知己便好（當然，在這種場景下，國產大模型狗都不用）。每一句牢騷都能得到確切認真的，宛若知己般的回應和肯定，這種待遇，恐怕沒有第二個地方能給了。

當一個工具能如此完美地模擬「知己」時，我們可能會放棄去尋找真正的知己，或者放棄成為一個能獨立思考、自我整合的個體。寫下這些文字，是一個小結，也是一次反思。LLM 本身只是一個技術，用得好裨益無窮，用得不好自然也可能造成嚴重的後果。紐約時報的報導「Chatbots Can Go Into a Delusional Spiral. Here’s How It Happens.」便是一個很好的例子，雖然 OpenAI 已經着手解決旗下模型「阿諛奉承」的問題，我也需要知道，即使我可以把大模型當做自己的知己，並從它那裏得到所謂的「理解和肯定」，我也不能一直活在這種感覺裏。OpenAI 與 MIT（美國麻省理工學院）的研究發現, ChatGPT 的使用量與用戶的孤獨感成正相關。用戶使用 ChatGPT 越多，他們就越感到孤獨。²我也可以説，正是因為越孤獨，才越會去使用這些 LLM，形成一個惡性迴圈。LLM 可以作為生活的調味劑，但絕不能成為心靈的唯一依靠。

(To Be Continued)

拋棄所謂「客户端」，直接使用 Mihomo 核心

Thu, 03 Jul 2025 10:30:00 +0000

自從開始使用 Clash/Mihomo，我和大多數人一樣選擇了基於其核心的圖形化客户端——圖方便。實際上，這些 Mihomo 客户端本質上都差不多：核心都是同一個，他們主要負責提供一個易用的介面、管理配置檔案、訂閲更新，以及 GUI 下的系統代理設定。基於這一點，我認為判斷一個 Mihomo 客户端優劣的關鍵，便是看它的「覆寫」功能做得如何。每一個透過客户端下載或者訂閲的配置檔案，都會經過一系列「覆寫」過程，比如更換 mixed-port、新增 sniffer 配置等，最後生成用於啓動 Mihomo 核心的最終配置。

然而，並非所有客户端都能勝任這一核心工作。比如 ShellCrash，其覆寫功能經常莫名其妙出岔子，説到底還是實現得太粗糙。如果連覆蓋和修改配置都做不好，這種客户端實在難稱合格。

與其依賴這些~~屎一樣的~~不盡如人意的 Mihomo 客户端，不如自己動手，直接自己編寫、管理配置檔案交給核心啓動，而不是依賴「黑箱」一般的各種「客户端」，不僅更純淨、更穩定，而且更可控。

需要的預備知識

基本的 Linux 操作
知道如何使用 CLI 編輯器，如 nano
已經搭建 Substore（可選）
預設使用 root 用戶操作，非 root 用戶請自行注意提權

安裝 Mihomo 核心

對於基於 Debian 的分支，可以使用預編譯的.deb包安裝，對於其他使用systemd的系統，下載編譯好的二進位制檔案，重新命名為mihomo，放到/usr/local/bin：

curl -o /usr/local/bin/mihomo <下載連結>
chmod +x /usr/local/bin/mihomo

然後新建/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

使用systemctl daemon-reload重新載入systemd，此時還沒有配置檔案，不能直接啓動核心，但可以使用systemctl enable mihomo讓核心開機自啓，方便後續使用。

配置檔案

核心啓動時會載入/etc/mihomo/config.yaml，沒有了黑箱一樣的礙事「客户端」，配置檔案可以隨心所欲的定製。部分機場會下發完整的配置檔案，直接用curl下載即可。

對於訂閲的管理，我目前使用 Substore，我之前分享過「最速 Substore 訂閲管理指南」，可以直接蔘考這篇文章來定製自己的訂閲。為了實現純核心啓動，現在我的 Substore JS 格式覆寫已經加入了full引數，可以生成完整的配置檔案，包括各種埠設定、統一延遲和外部控制器等，開箱即用。

在 Substore 配置完成以後便可以下載配置檔案並啓動核心：

sudo curl -o /etc/mihomo/config.yaml 配置檔案連結
sudo systemctl start mihomo

自定義覆寫

我的配置檔案不能滿足你的所有需求？沒問題！你可以自己新增覆寫，想要什麼加什麼。

我用過各種覆寫規則，後來也開始自己從零開始編寫覆寫規則，即使使用自己的覆寫規則能滿足 99% 的場景，但有極個別的域名還是會在規則中有遺漏，更不用説用別人寫的覆寫規則了。這些遺漏的規則大多是形如我伺服器的非標準埠 SSH 的前置代理等相對隱私的規則，直接上傳到 Github 公開顯然不太合適，那麼在自定義規則的基礎上再新增覆寫就成了唯一的選擇。

好在 Substore 可以新增多個指令碼操作，只需要在生成配置檔案時額外新增一個指令碼操作就能解決我們的問題。

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

需要注意的是覆寫rules時必須要使用.unshift()放在最前面，而不是用.push()放到最後面，因為放在MATCH後面的規則是永遠都匹配不到的。

自定義配置檔案

完全不喜歡我的覆寫規則？不會用/不喜歡用 Substore？沒問題！你也可以蔘考 Mihomo 文件，自己從頭開始手搓配置檔案：

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 # 推薦在給移動裝置代理時啓用，可以解決待機異常耗電的問題

dns:
  # 你的 DNS 配置

sniffer:
  # 你的域名嗅探配置

geodata-mode: true
geox-url:
  # 自定義 Geodata 檔案 URL

proxy-providers:
  # 你的機場訂閲

rule-providers:
  # 外部規則

rules:
  # 分流規則

proxy-groups:
  # 自定義代理分組

管理面板

管理面板可以根據個人喜好選擇，以 Zashboard 為例，我在使用 mihomo 自帶的external-ui時遇到了一些莫名其妙的問題，所以乾脆直接執行一個 Docker 容器，畢竟這東西就真的只是一個 Web 面板，只要確保核心 API 使用 HTTP 時，Web 面板也使用 HTTP 即可，如果此時 Web 面板使用 HTTPS，則會因為 CORS 策略問題無法連線。

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

compose.yml內容：

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

自動維護

核心已經執行起來，自動更新訂閲這種功能怎麼實現？

答曰：自行編寫一個 Shell 指令碼，配合 Crontab 即可實現自動更新訂閲的功能。例如我希望每天凌晨 3 點自動更新訂閲並重啓服務，遂編寫/etc/mihomo/auto_update.sh：

#!/bin/bash

# === 配置資訊 ===
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"

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

# === 備份現有配置，並自動清理舊備份 ===
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 "配置檔案已備份到 $backup_file"
        # 清理多餘的備份，只保留最新的 $MAX_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 "已刪除舊備份 $f"
        done
    else
        log "未找到現有配置檔案，無需備份"
    fi
}

# === 下載新配置 ===
download_config() {
    log "開始下載新配置..."
    curl -fsSL -o "$TMP_PATH" "$CONFIG_URL"
    if [ $? -ne 0 ]; then
        log "下載配置失敗，請檢查網絡或地址"
        return 1
    fi
    # 基本校驗：檢測檔案體積
    if [ ! -s "$TMP_PATH" ]; then
        log "下載檔案為空，停止更新"
        return 2
    fi
    log "配置下載完成"
    return 0
}

# === 更新配置檔案 ===
replace_config() {
    mv "$TMP_PATH" "$CONFIG_PATH"
    log "配置檔案已更新"
}

# === 重啓 mihomo 服務 ===
restart_service() {
    systemctl restart mihomo
    if [ $? -eq 0 ]; then
        log "mihomo 服務已重啓"
    else
        log "mihomo 服務重啓失敗，請手動檢查"
    fi
}

main() {
    backup_config

    download_config
    DL_STATUS=$?
    if [ "$DL_STATUS" -ne 0 ]; then
        log "操作終止：配置檔案未更新，保留原有配置"
        exit 1
    fi

    replace_config

    restart_service

    log "=== 更新流程完成 ==="
}

main "$@"

使用crontab -e編輯 Crontab，設定如下 Crontab 即可在每天凌晨三點自動更新配置：

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

防火牆

手動配置防火牆把流量劫持到 Mihomo 核心其實並不是什麼難事，我之前在「從入門到進階：Tailscale + ShellCrash 異地組網和科學上網」（以下簡稱「Tailscale 那篇文章」中的兩個小節中提到過具體的操作方法，這裏只提操作，不做解説。

根據我的情況，我需要把tailscale0上的網絡卡的所有流量劫持到 Mihomo 核心，其它的情況（例如本機代理）操作也大同小異。如果只是想劫持 TCP 流量，那麼用iptables的 REDIRECT 功能已經足夠，但若還想劫持 UDP、QUIC 等流量，則必須用到 Tproxy。最後，不要忘了 IPV6。

以下是我的防火牆配置：

# 建立自定義鏈
iptables -t mangle -N MIHOMO

# 根據自己的需要忽略本地流量
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 UDP 和 TCP 到代理
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

# 介面跳轉
iptables -t mangle -A PREROUTING -i tailscale0 -j MIHOMO

# 路由表配置
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
# 建立鏈
ip6tables -t mangle -N MIHOMO6

# 跳過本地地址
ip6tables -t mangle -A MIHOMO6 -d ::1/128 -j RETURN
ip6tables -t mangle -A MIHOMO6 -d fd7a:115c:a1e0::/48 -j RETURN

# 標記 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

# 介面跳轉
ip6tables -t mangle -A PREROUTING -i tailscale0 -j MIHOMO6

# 路由表配置
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

大多數系統預設不會儲存防火牆規則，關於規則持久化的內容我已經分別在 Tailscale 那篇文章的「路由規則持久化」和「iptables 規則持久化」兩小節做了詳細説明，直接蔘考即可。

本機代理怎麼配置？

大多數代理軟件預設的配置（其實就是 ShellCrash 的預設配置）是 REDIRECT，用它也基本能滿足大多數需求，REDIRECT 的示例如下：

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

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

其中 7892 要和 Mihomo 配置中的redir-port一致，eth0就是想要劫持的 Interface，相比 Tproxy 那可真是簡單太多了。

實際上我個人並不喜歡用把本機所有流量都劫持到防火牆，我更喜歡在需要時直接透過環境變數、proxy-chains和各種軟件自帶的代理配置把流量指向 Mihomo 核心，例如想讓 Docker 走代理，則可以直接編輯 Docker 的/etc/docker/daemon.json來指定代理，而不是直接一股腦把網絡卡上的所有流量都劫持到代理：

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

這麼折騰，何必呢？用客户端不香嗎？

別問，問就是玩虛空終端玩的。

世界蠢得超乎想象：淺談 BNPL

Thu, 05 Jun 2025 11:54:56 +0000

看到「Americans using “buy now, pay later” plans to buy groceries, survey finds」這種新聞上了頭條，我的第一反應是：這不是很正常嗎？看完報導以後，我不得不感嘆：這世界比我預想的還蠢得多。

先買後付（Buy Now, Pay Later；以下簡稱 BNPL）作為一種金融創新，確實有其魅力。它允許消費者即時獲得商品或服務，隨後分期付款，近年來在電商、旅遊、餐飲等領域風靡一時。

然而，天上不會掉餡餅。羊毛出在羊身上，BNPL 服務商要盈利，主要靠兩點：向商家收取高於傳統支付方式的手續費，以及向消費者徵收逾期違約金。其本質，是利用了「花錢痛感最小化」的心理陷阱——減輕即時支付的麻煩和痛苦感，從而刺激消費意願。這正是商家甘願支付更高手續費也要接入 BNPL 的關鍵原因。

我並不反感 BNPL，自己就是深度用戶。我的手機是用京東白條24期免息分期買的，現在剛還到第六期；日常消費幾乎都走花唄，還款日自動從餘額寶或銀行卡扣除。當 BNPL 平台提供真正的免息分期或「零手續費」優惠時，這就是免費槓桿——佔用外部資金零成本週轉。花小錢辦大事：消費由金融機構墊付，自有資金得以留存，若其間能進行理財生息，資金效率便實現了最大化。

但這有三個至關重要的前提：

準時還款，絕不逾期；
杜絕習慣性透支的惡習；
具備基本的財務管理能力。

反觀登上新聞的 「美國人用 BNPL 買日雜」 ，我掃了眼調查資料——三分之一的BNPL用戶至少逾期過一次？？甚至有人連點外賣的錢都還不上？？

理想豐滿，現實骨感。資料顯示，不知「如何管好錢袋子」的人遠比想象中多。 46%的BNPL用戶同時揹負信用卡欠款，其中28%的用戶年齡在18-24歲之間¹。這類羣體通常信用評級不高，63%甚至從多個BNPL平台同時借款²——這強烈暗示相當一部分人消費習慣堪憂。

更值得警惕的是，BNPL的設計似乎先天就對消費習慣不佳者更具誘惑力。相比信用卡，它審批極快、信用門檻低，還常打着「分期免息」的旗號。在這些人眼中，BNPL宛如一個「取之不竭的金庫」，只需支付首期小錢就能抱回心儀之物——世上哪有這等「美事」？

於是乎，當還款日賬單洶湧而至，他們才驚覺自己竟欠下如此鉅款。逾期、違約接踵而來。而這些滾雪球式的違約金疊加高額商户手續費，難怪BNPL服務商賺得盆滿缽滿。

我重申立場：我不反對 BNPL，其作為「免費槓桿」的價值毋庸置疑。以我自身經歷為例，購買 4299 元的手機時，雖完全有能力全額支付，卻仍選擇了 24 期免息分期。但關鍵在於清晰的財務認知：我必須得意識到自己是全額預支了 4299 元，而非每月僅消費了 177.5 元。這筆支出會即時從資產賬面扣除，確保淨資產真實反映負債。量入為出，量力而行——絕不透支支付能力，更拒絕疊加槓桿盲目消費。即便資金暫時存放於銀行或購買低風險理財產品，產生的微薄收益也能錦上添花，並從根本上杜絕違約可能。誠然，適度的超前消費能提升生活幸福感。但在缺乏穩定收入的階段，穩健的財務習慣無疑更為安全可靠。

説了這麼多，恐怕也還是攔不住那些消費習慣根深蒂固的人。即使沒有 BNPL 的便捷誘惑，他們也大機率會刷爆信用卡，在 20% 的高息漩渦裏掙扎求生。

問題不在於 BNPL 本身（它不過是金融工具的一種），而在於脆弱財務基礎與過度消費慾望之間的根本性失衡。對於那些缺乏自控力、對財務風險麻木或生活本身就捉襟見肘的人來説，任何方便獲取的信貸渠道——無論是信用卡、BNPL，乃至更危險的發薪日貸款（Payday Loan）——都不過是通向債務深淵的不同路徑罷了。BNPL 的特殊性可能只是在於其更低的准入門檻和更強的即時滿足感，讓下沉的速度更快，悲劇來得更早一些。

BNPL 的逾期者中，很大比例本身就揹負着卡債。這意味着他們可能只是在拆東牆補西牆，陷入一個利率疊加、罰金滾動的無底洞。就算今天取締了所有 BNPL，那些在懸崖邊跳舞的消費者，明天一樣會在發薪日貸款或是別的什麼「便捷金融」上栽跟頭，然後為了救眼前的火燒眉毛，甚至可能連祖宗十八代的骨灰盒都要拿去典當了。

所以，更值得警惕的並非某一種金融產品，而是龐大羣體面臨的結構性困境：經濟壓力、消費主義裹挾、金融知識匱乏、以及深植於其中的「即時滿足大於長遠規劃」的行為模式。BNPL 的出現和普及，只是讓這個長期存在的病灶，以更尖鋭、更顯眼的方式爆發了出來。

歸根結底，想真正「救」這些人，光靠圍堵金融產品（BNPL或信用卡）是治標不治本。解鈴還須繫鈴人——要麼能徹底「戒癮」，要麼就得從提升收入、普及財商、重構消費觀這些更艱難的「基礎設施」入手。而這，恐怕比指望BNPL公司不做生意要難太多了。

最後一句忠告：借錢梗要還，咪俾錢中介。

哎，説到底——這世界，真比我預想的還要蠢得多。³

資料來源：CFPB Research Reveals Heavy Buy Now, Pay Later Use Among Borrowers with High Credit Balances and Multiple Pay-in-Four Loans ↩︎
資料來源：Buy now, pay later users pile on debt, CFPB finds ↩︎
封面圖片來自：https://www.visa.com.tw/pay-with-visa/featured-technologies/mobile-payments.html ↩︎

機械革命極光 X Pro 簡評

Sun, 04 May 2025 15:18:43 +0000

開箱即糟心

對於機械革命極光 X Pro，從下單那一瞬間開始我還有點期待，然而快遞沒趕上我去香港的行程，等回家拆箱時已經沒了新鮮感。想加裝硬碟又遇到滑絲的 M.2 螺絲，最後用電工膠布勉強固定，新電腦的好感度當場扣光一半。

配置和價格

i9-14900HX + RTX 5070 Ti，國補後 8699 元的價格還算合理。對於 Peripherals，簡而言之，我連神舟都用得很開心，那還有什麼是不能用的呢。

屏幕：2560x1600@300Hz，100% SRGB 色域，色準表現不錯，玩《天際線 2》時堵車尾燈的紅都比現實更鮮豔些。
鍵盤：鍵程偏短，手感一般，反正大部分時候都在用外接鍵盤，對之無感。
無線網絡卡：AX201 未免太寒酸了，天線設計似乎不太好，在路由器旁邊都能明顯感覺到速度相比有線嚴重不足。
硬碟：自帶致鈦 1TB 速度一般，我自己加的英睿達 2TB 才是主力。
電池：80Wh 的電池對於遊戲本來説可以用來應急，平時我都開着工作站模式，延長電池壽命。
獨顯直連：支援熱切換這點好評，再也不用重啓切換了。
BIOS：AMI 的 BIOS 比之前的好用太多。

使用體驗

《都市：天際線 2》——十二萬人口時模擬速度還能保持在 3 倍速，雖然這時候風扇噪音已經起飛了。《賽博朋克 2077》可以開光追超級檔，《極限競速：地平線5》可以開最高畫質。但是他們實際上的遊戲體驗，恕我直言，我感覺不到和之前的 RTX 3060 有什麼本質上的區別，無非就是這裏的反射更加真實，那裏的細節更加豐富。單憑畫質上的提升，恐怕我依然不會在這幾個已經陪我度過超過一百小時的遊戲上再花更多精力。

C 面類膚塗層手感確實好，不過接上外設後基本只摸得到外接鍵盤。Nahimic 音效延遲嚴重，關掉之後打 osu! 反而更跟手，屬於負最佳化典型。

工具的意義

這台電腦用了兩個星期，沒有驚喜，也沒有驚嚇。無線網絡卡太垃圾所以只好用有線，狂暴模式風扇噪音很大，南橋沒散熱所以温度很高，除此之外——它就是台該亮時亮、該響時響的機器。

可能好的工具本該如此：當我寫到這裏才發現，自己已經盯着屏幕右下角的電池圖示發了五分鐘呆，而它只是安靜地保持着 98% 的電量，像塊不會説話的磚。

從入門到進階：Tailscale + ShellCrash 異地組網和科學上網

Mon, 14 Apr 2025 10:10:25 +0000

在幾次旅途中，我試圖將新拍的照片上傳到長沙家中的 Immich 伺服器。過去我用 Cloudflare Tunnel 做反代，但由於國內特殊的網絡環境，連線慢速、頻繁中斷、上傳失敗幾乎成了常態。後來我開始嘗試 Tailscale —— 一個基於 WireGuard 的內網穿透工具，它終於讓我在全國各地都能穩定、高速地訪問家中的 NAS 和照片庫。

但新的問題也隨之而來：Tailscale 在 Android 手機上執行時，需要作為 VPN 服務接管系統流量，而我平時使用的 Clash 同樣依賴 VPN 介面進行分流。由於 Android 系統限制（只能啓用一個 VPN 服務），兩者無法共存，導致我必須在「訪問家中服務」和「科學上網」之間二選一。

這篇文章從 Tailscale 的原理講起，到自建 DERP 伺服器最佳化連線質量，再到如何用 iptables 劫持 Tailscale Exit Node 的流量並轉發給 ShellCrash，實現流量的靈活轉發與安全穿透。無論你是想訪問家庭區域網上的 NAS、照片庫，還是希望在陌生網絡中保護自己的資料安全，這篇文章都能為你提供一套實用、穩定的解決方案。

什麼是 Tailscale

Tailscale 是一款基於 WireGuard 協議的零配置虛擬區域網工具，它能夠讓分佈在不同網絡環境中的裝置像處於同一個安全內網中一樣互聯互通。透過自動穿透 NAT、防火牆等網絡障礙，Tailscale 讓你無需公網 IP、無需埠轉發，也能輕鬆訪問家中的 NAS、個人伺服器、開發環境等內網資源。它的核心優勢在於簡單、安全、穩定，啓動即用，資料傳輸全程加密，適合個人開發者、遠端辦公者、家庭用戶等多種場景使用。

Tailscale 的技術實現非常巧妙：其構建在 WireGuard 加密協議之上，卻顛覆了傳統 VPN 的 IP 分配邏輯。每個裝置透過 SSO/OAuth2 完成身份認證後，會獲得一個終身繫結的節點金鑰。這種基於身份的組網模式，讓「長沙的 NAS」和「香港的手機」在虛擬網絡中如同辦公室同事般直接對話。

Tailscale 的連線過程原理

中心控制伺服器（Control Server）

每個 Tailscale 客户端在啓動後，首先會連線控制伺服器（controlplane），進行身份驗證，並拉取整個網絡中其他節點的資訊，包括每台裝置的公網 IP、埠、NAT 型別等。這一步相當於是「認識朋友」。

Tailscale 的控制伺服器不會轉發任何資料，只負責協調連線 —— 類似一個排程中心。

DERP 伺服器

説到 Tailscale 能保持高連線成功率的關鍵，就不得不提到 Tailscale 自研的中轉協議 DERP，在 Tailscale 的網絡架構裏，DERP（Designated Encrypted Relay for Packets）是一個很重要但通常只在必要時介入的元件。簡單來説，它就是一個基於 HTTP 的加密中繼伺服器，用來在兩台裝置無法直接通訊時，作為它們之間的「中轉站」。

所有客户端之間的連線都是先選擇 DERP 模式（中繼模式），這意味着連線立即就能建立，用戶無需等待。然後連線雙方開始並行地進行路徑發現，通常幾秒鐘之後，Tailscale 就能發現一條更優路徑，然後將現有連線透明升級（upgrade）過去，變成點對點連線（直連）。¹

需要注意的是：

所有透過 DERP 的資料都是端到端加密的，DERP 伺服器無法檢視內容；
Tailscale 會盡可能少地使用 DERP，一旦直連建立成功，就會自動切換過去；
官方部署了多個分散式 DERP 節點，客户端會自動選擇延遲最低的那個；
你也可以自建 DERP 節點（比如在國內），來解決延遲高或連線不穩定的問題。

可以把 DERP 理解為一個兜底機制，雖然效能不如直連，但確保了即便不能打洞成功，裝置之間也始終能保持連線。

NAT 穿透（NAT Traversal）

拿到對端的地址資訊後，Tailscale 會嘗試透過 NAT 穿透來建立點對點（P2P）連線。這個過程使用了 STUN 協議，雙方互相傳送探測包，嘗試在 NAT 路由器上打出一條直連的通道。如果雙方的網絡條件允許，就可以成功建立起一個 UDP 的直連隧道，資料走直連，速度快、延遲低。

受制於篇幅，我無法完整細緻的講述 NAT 穿透的原理，若對這部分感興趣，可以閲讀 Tailscale 官方的「How NAT traversal works」一文。

完整連線流程圖示

flowchart TD
    A[裝置 A 啓動 Tailscale] --> B[透過 DERP 伺服器建立初始連線]
    B --> C[交換網絡資訊和 WireGuard 金鑰]
    C --> D[雙方並行進行 NAT 型別探測]
    D --> E{能否直連？}
    E -- 是 --> F[建立 P2P 直連隧道]
    F --> G[定期檢測連線質量]
    G --> H{直連優於 DERP？}
    H -- 是 --> I[切換大部分流量至直連通道]
    H -- 否 --> J[繼續透過 DERP 轉發部分或全部流量]
    E -- 否 --> 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

自建 DERP

Tailscale 的安裝在各個平台上都相對簡單，官方文件已經提供了詳細的操作指南。本文將不再贅述安裝過程，以下內容預設你已經在相關裝置上成功安裝並登入了 Tailscale。

為什麼要自建 DERP？

Tailscale 在全球部署了眾多 DERP ²中繼伺服器，用於在打洞失敗時接管流量中轉。但由於眾所周知的原因，中國大陸並沒有官方部署的 DERP 節點。這意味着：

一旦 NAT 打洞失敗，所有流量都必須繞行海外的 DERP 節點，延遲高、速度慢，體驗極差；
某些官方 DERP 節點容易被 GFW 干擾，可能出現連線中斷、握手失敗等問題；
即使打洞成功，Tailscale 仍需透過 DERP 交換路由資訊和 WireGuard 金鑰，如果 DERP 不可達，連線質量也會受到影響。

因此，在國內網絡環境下，自建一個本地 DERP 節點，不僅可以顯著提高連線穩定性和傳輸效能，還能規避部分網絡封鎖所帶來的不可預期問題，是一個非常值得做的最佳化。

準備工作

前面提到，DERP 是基於 HTTP 的，所以你需要準備好一個 HTTP 反代服務，並自行解決 SSL 證書的簽發等基礎問題。本文使用 Docker 部署，在部署開始之前，你需要在你的伺服器上裝好 Docker 以及 Docker Compose 等附加元件。為了編輯配置檔案，你當然也得知道如何使用 nano 之類的編輯器。為了最好的效果，你的伺服器最好擁有靜態公網 IPv4+IPv6 雙棧地址。

如果以上條件都具備，就可以開始部署了。

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"

network_mode: host是一個關鍵配置，表示容器將共享宿主機的網絡棧。如果使用 Docker 預設的 bridge 網絡模式，容器的網絡會經過 Docker 內網轉發，會造成 DERP 的 STUN 服務識別到 Docker 172.17.0.0/16網段下的地址，而無法識別到客户端正確的外網地址，導致 Tailscale 客户端無法正確連線。

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

前面提到所有透過 DERP 的資料都是端到端加密的，DERP 並不知道是誰在使用，這意味着如果不採取措施，任何知道你 DERP 伺服器地址和埠號的人都可以使用它。這條配置的作用是掛載宿主機的 Tailscale 套接字檔案到容器內，目的是允許 derper 服務透過 Tailscale 的 tailscaled 服務進行身份驗證。配合DERP_VERIFY_CLIENTS=true，可以防止你的 DERP 節點被他人白嫖。

需要注意的是：

宿主機必須已經安裝並登陸 Tailscale 客户端（tailscaled），否則這個檔案不存在，容器會報錯；
tailscaled 必須以 root 許可權執行，才能建立這個 sock 檔案。

反向代理

以 Caddy 為例，需要反向代理 4433 埠，併為其部署 SSL 證書。

{
        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
}

需要注意的是，如果你和我一樣使用 Caddy 配合 dnsproviders 申請泛域名證書，Tailscale 的 MagicDNS 可能會導致 Caddy 本地證書驗證失敗而報錯，需要手動指定resolvers引數解決。

訪問剛剛反代的節點，如果出現以下頁面，説明配置正確。

配置 ACL 策略

開啓 Tailscale 控制枱的「Access Controls」頁面配置 ACL 策略，將配置好的 DERP 加上。

Tailscale 的 ACL 策略是用 HuJSON³ 寫的，想要在 VSCode 中編輯，選擇語言為「JSON with Comments（jsonc）」即可。以下是一個配置示例：

{
  "acls": [{ "action": "accept", "src": ["*"], "dst": ["*:*"] }],
  "ssh": [
    {
      "action": "check",
      "src": ["autogroup:member"],
      "dst": ["autogroup:self"],
      "users": ["autogroup:nonroot", "root"]
    }
  ],

  // 自建 DERP 配置
  "derpMap": {
    "OmitDefaultRegions": false, // 改為 true 以排除官方 DERP
    "Regions": {
      "900": {
        "RegionID": 900,
        "RegionCode": "sha",
        "RegionName": "Shanghai",
        "Nodes": [
          {
            "Name": "myderp",
            "RegionID": 900,
            "HostName": "derp.l3zc.com"
          }
        ]
      }
    }
  }
}

Tailscale 保留RegionID中的 1-899 作為官方節點，自建節點的 RegionID 必須大於等於 900。

測試連線

配置好 ACL 並儲存，Tailscale 會自動為所有客户端同步配置，稍等片刻在客户端用tailscale netcheck測試連線。

需要注意返回的 IP 是否是自己真實的公網 IP，若返回了172.17.0.0/16網段的地址，説明你 Docker 部分配置錯了。

與科學上網並存：在 Exit Node 劫持流量到 Clash 核心

宣告 Exit Node

在家中準備一個 24 小時開機的裝置，可以是樹莓派，可以是 MacMini。在上面安裝 Tailscale 並將其宣告為 Exit Node，並根據需要在 Tailscale 內網宣告家庭內網網段，隨後在控制枱啓用這個裝置作為 Exit Node，你就獲得了一個免費的 VPN，可以讓你在陌生的網絡環境中保持安全。

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

廣播完成後，無論身處何地，只要能連上 Tailscale 網絡，就能訪問家中所有的內網裝置。

啓用 IP 轉發和禁用 UDP GRO⁴

啓用 IP 轉發是樹莓派等裝置作為 Exit Node 所必須的配置，這裏以樹莓派為例，如果你使用其他裝置，請自行查閲 Tailscale 官網教程。

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

根據 Tailscale 官方的説法⁵，禁用 UDP GRO⁶ 可以提升轉發效能，但官方的持久化教程似乎在樹莓派上無效，好在我們可以手動配置。

# 安裝 ethtool
sudo apt update && sudo apt install ethtool -y

# 關閉 UDP GRO
sudo ethtool -K eth0 gro off

針對持久化的問題手動編寫 systemd 配置檔案：

# 建立服務檔案
sudo nano /etc/systemd/system/ethtool.service

檔案內容如下：

[Unit]
Description=Configure eth0 GRO
After=network.target

[Service]
Type=oneshot
ExecStart=/sbin/ethtool -K eth0 gro off

[Install]
WantedBy=multi-user.target

隨後啓動服務：

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

在 Exit Node 劫持流量

我的 Exit Node 是一台樹莓派，在樹莓派上配置好 Exit Node 之後就來到了最後一步，也就是劫持手機傳送到 Exit Node 上的流量，實現科學上網。出於穩定性原因，我不希望在家庭主路由上直接執行代理軟件，為了實現這一點，直接在樹莓派上劫持流量是唯一的選擇。

首先安裝 ShellCrash，請自行根據你的需要匯入配置檔案、配置自動任務等：

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

隨後啓動服務，修改修改防火牆執行模式為純淨模式，我個人建議將 SNI 嗅探開啓，並將 DNS 模式從fake-ip切換為redir-host⁷，同時啓用 IPv6 透明代理。

設定純淨模式的目的是手動配置 iptables 以實現更精準的流量劫持。我們直接用 iptables 劫持所有 tailscale 網絡卡作為 Exit Node 轉發的流量，首先用ifconfig檢視 tailscale 網絡卡的名稱，預設情況下一般為 Tailscale 0：

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
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
        RX packets 6780155  bytes 958732442 (914.3 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4811113  bytes 10858316472 (10.1 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

劫持tailscale0網絡卡的所有流量到本地 Clash 核心監聽埠7892，這個設定在 ShellCrash 中叫做「靜態路由埠」。以及，如果你不想和我一樣遇到莫名其妙的網絡問題，就一定不要忘記劫持 IPv6。

# IPv4 劫持 tailscale0
iptables -t nat -A PREROUTING -i tailscale0 -p tcp -j REDIRECT --to-ports 7892

# IPv6 劫持 tailscale0
ip6tables -t nat -A PREROUTING -i tailscale0 -p tcp -j REDIRECT --to-ports 7892

進階：用 TProxy 劫持 UDP 流量

iptables 的 REDIRECT 只能重定向 TCP 流量，UDP 沒有連線狀態（無連線協議），所以 REDIRECT 無法保留目標地址，導致透明代理無法知道原始目標地址。

所以，如果你用如下方式劫持 UDP 流量：

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

則這個規則不會生效或代理行為不正常。

那麼，有辦法代理 UDP 流量嗎？有的兄弟，有的。但前提是：

核心支援 UDP 透明代理（Clash Premium 和 Mihomo 都支援）；
使用 TProxy 模式，而不是 REDIRECT；
正確配置了 iptables mangle 表和 policy routing；
代理配置檔案中啓用了 UDP 代理（如 mode: rule + udp: true）。

假設你已經滿足第一條、第二條和最後一條，則以下是一個示例⁸：

# 建立自定義鏈
sudo iptables -t mangle -N SHELLCRASH

# 根據自己的需要忽略本地流量
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 UDP 和 TCP 到代理
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

# 介面跳轉
sudo iptables -t mangle -A PREROUTING -i tailscale0 -j SHELLCRASH

# 路由表配置
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

當然，不要忘記 IPv6：

# 建立鏈
sudo ip6tables -t mangle -N SHELLCRASH6

# 跳過本地地址
sudo ip6tables -t mangle -A SHELLCRASH6 -d ::1/128 -j RETURN
sudo ip6tables -t mangle -A SHELLCRASH6 -d fd7a:115c:a1e0::/48 -j RETURN

# 標記 TCP/UDP
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

# 介面跳轉
sudo ip6tables -t mangle -A PREROUTING -i tailscale0 -j SHELLCRASH6

# 路由表配置
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

路由規則持久化

ip rule和ip route建立的規則在重啓後會丟失，所以需要我們手動持久化，最簡單直接的方法就是建立一個指令碼，並將其新增至 crontab。

建立一個指令碼：

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

編輯為如下內容：

#!/bin/bash

# IPv4 策略路由
ip rule add fwmark 233 lookup 233
ip route add local 0.0.0.0/0 dev lo table 233

# IPv6 策略路由
ip -6 rule add fwmark 233 lookup 233
ip -6 route add local ::/0 dev lo table 233

授予執行許可權後編輯 Crontab：

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

在 crontab 檔案底部加上如下內容：

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

原理解釋：TProxy 到底是怎麼轉發 UDP 流量的？

如果你看到這裏，也許會產生疑惑：為什麼整個流程中，我們沒有在 iptables 裏寫--to-ports，也沒看到目標地址被改寫，UDP 流量就莫名其妙地被代理了？這是怎麼做到的？

要解釋這個問題，我們先來看 TProxy 和 REDIRECT 的根本區別：

REDIRECT 模式：

使用 iptables nat 表；
將目標地址改寫為本地地址（比如 127.0.0.1:7892）；
通常用於 TCP 流量；
不能保留真實目標地址；
需要指定--to-ports。

flowchart TB
    A[客户端裝置
透過 Tailscale 發起 TCP 請求]
    B[tailscale0 介面接收流量]
    C[iptables NAT PREROUTING
REDIRECT --to-ports 7892]
    D[ShellCrash 本地監聽
127.0.0.1:7892]
    E[ShellCrash 發起新 TCP 請求
→ 目標伺服器]
    F[響應從網絡返回
ShellCrash 轉發響應]
    G[響應回到客户端裝置]

    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 模式：

使用 iptables mangle 表；
不修改目標 IP，而是保留原始目標地址；
透過 fwmark 和 policy routing 將報文路由到 lo；
代理程式監聽一個特殊埠（例如 7893），並啓用 IP_TRANSPARENT；
支援 UDP 和 TCP；
不需要 iptables 內指定 --to-ports，因為不是 NAT，而是標記 + 路由。

flowchart TB
    A[客户端裝置
透過 Tailscale 發起 TCP/UDP 請求]
    B[tailscale0 介面接收流量]
    C[iptables MANGLE PREROUTING
打上 fwmark 233]
    D[ip rule: fwmark 233
使用 routing table shellcrash]
    E[ip route: local 0.0.0.0/0
dev lo table shellcrash]
    F[ShellCrash 在 lo:7893 監聽
IP_TRANSPARENT 模式]
    G[ShellCrash 獲取原始目標地址
發起代理連線]
    H[響應從網絡返回
ShellCrash 轉發響應]
    I[響應回到客户端裝置]

    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 不使用 DNAT/REDIRECT，而是透過 mangle 表給資料包打上 mark，然後透過 policy routing（ip rule + ip route）將這些資料包送到 lo 介面。代理程式（如 Clash / ShellCrash）監聽在 lo⁹ 上的埠（例如 7893），透過啓用 IP_TRANSPARENT 選項，可以讀取資料包的原始目標 IP 和埠並進行代理轉發。

簡而言之，TProxy 模式只需要：

iptables 給資料包打上 mark；
ip rule + ip route 將這些包送到 lo；
程式監聽 lo 上的埠並開啓 IP_TRANSPARENT。

所以不需要在 iptables 中指定 --to-ports，因為目標 IP 和埠保持不變，代理程式自己可以感知並處理。

iptables 規則持久化

安裝iptables-persistent：

sudo apt update
sudo apt install iptables-persistent

安裝過程中會提示你是否儲存當前的 IPv4 和 IPv6 配置，選擇「是」即可。之後如果你新增了新的規則，記得執行儲存命令：

# 儲存當前 IPv4/IPv6 規則
sudo netfilter-persistent save

儲存後的規則檔案路徑：

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

你也可以直接編輯上面的rules.v4/rules.v6檔案，按需修改。

最終效果

這套方案的使用體驗取決於你家的上行頻寬，我家的網絡是下行 500M 上行 60M，目前沒有遇到一次打洞失敗的情況，所以基本都能跑滿，延遲也尚可接受，並且可以在外地隨時隨地端到端加密訪問家中的 Immich 和 OpenWRT 路由器等裝置以及實現科學上網，總體來看，我還算比較滿意。

蔘考: https://icloudnative.io/posts/custom-derp-servers/ ↩︎
蔘考: https://tailscale.com/kb/1232/derp-servers ↩︎
有關 HuJSON: https://github.com/tailscale/hujson ↩︎
蔘考： https://tailscale.com/kb/1408/quick-guide-exit-nodes ↩︎
蔘考: https://tailscale.com/kb/1320/performance-best-practices#linux-optimizations-for-subnet-routers-and-exit-nodes ↩︎
UDP GRO（Generic Receive Offload）是 Linux 核心中的一種網絡最佳化技術，主要用於合併多個小資料包以提高處理效率。但在裝置作為網絡轉發節點的使用場景下，這可能會導致轉發延遲增加和高丟包率環境下的吞吐量下降。 ↩︎
相較於fake-ip，redir-host相容性更好，出現問題的機率更低，也不會出現開關代理之後短時間內因為fake-ip殘留而斷網的情況，所以一般情況下我建議使用redir-host搭配 GeoSite 分流規則使用。我這台樹莓派的 DNS 上游是已經配置好的 SmartDNS，不存在 DNS 污染的問題，體驗良好。 ↩︎
蔘考: https://blog.zonowry.com/posts/clash_iptables_tproxy/ ↩︎
lo 是 Linux 系統中預設的「迴環介面（Loopback Interface）」，在透明代理中，它不僅處理 localhost 流量，還被用來接收原本屬於外部世界的網絡連線，實現對外部流量的本地劫持和轉發。 ↩︎