• 只暴露公网 80 和 443。
• 使用 Nginx Proxy Manager 统一管理 HTTPS、证书和反向代理。
• Marzneshin 面板通过 https://<PROXY_DOMAIN>/dashboard/ 访问。
• 代理节点使用 VLESS + WebSocket + TLS，客户端连接 <PROXY_DOMAIN>:443。
• Xray 实际后端只监听 Docker 网关 172.17.0.1:2087，不直接暴露到公网。
• Marzneshin 面板后端只监听 172.17.0.1:8000，不直接暴露到公网。
• Clash Verge / Mihomo 订阅自带分流规则：国内直连，Google / Telegram / GFW / 非中国域名走代理。
• 规则文件通过自己的域名反代：https://<PROXY_DOMAIN>/rules/google.txt，客户端不直接访问 GitHub 或 jsDelivr。
• 修复部分 Clash 客户端订阅名显示成 \"用户名\ 的问题。

示例环境：

系统：Ubuntu 22.04 LTS
服务器公网 IP：<SERVER_IP>
域名：<PROXY_DOMAIN>
面板端口：172.17.0.1:8000
Xray WS 后端端口：172.17.0.1:2087
WebSocket 路径：<WS_PATH>

实际使用时，把 <PROXY_DOMAIN>、用户名、密码、服务器 IP 替换成你自己的值。不要把真实密码写进博客或公开仓库。

1. DNS 准备​

先在你的 DNS 服务商处添加解析：

类型：A
主机记录：clash
记录值：<SERVER_IP>

等待生效后检查：

dig +short <PROXY_DOMAIN>

应该返回你的服务器公网 IP。

2. 安装 Docker 和 Docker Compose​

登录服务器：

ssh root@<SERVER_IP>

安装 Docker 官方源：

apt update
apt install -y ca-certificates curl gnupg lsb-release

install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
chmod a+r /etc/apt/keyrings/docker.asc

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" \
  > /etc/apt/sources.list.d/docker.list

apt update
apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

验证：

docker --version
docker compose version
docker run --rm hello-world

本文实测版本：

Docker version 29.5.2
Docker Compose version v5.1.4

3. 安装 Marzneshin​

Marzneshin 官方基础安装命令：

sudo bash -c "$(curl -sL https://github.com/marzneshin/Marzneshin/raw/master/script.sh)" @ install

安装完成后创建管理员：

marzneshin cli admin create --sudo

按提示输入管理员用户名和密码。示例：

username: admin
password: <ADMIN_PASSWORD>

安装后主要文件位置：

/etc/opt/marzneshin/.env
/etc/opt/marzneshin/docker-compose.yml
/var/lib/marzneshin/db.sqlite3
/var/lib/marznode/xray_config.json

初始状态下，面板通常可以通过：

http://<SERVER_IP>:8000/dashboard/

访问。后面我们会把它改成只监听 Docker 网关，由 NPM 统一暴露 HTTPS。

4. 安装 Nginx Proxy Manager​

创建目录：

mkdir -p /home/projects/nginx
cd /home/projects/nginx

写入 /home/projects/nginx/docker-compose.yml：

services:
    npm:
        image: "jc21/nginx-proxy-manager:latest"
        container_name: nginx-proxy-manager
        restart: always
        ports:
            - "443:443"
            - "127.0.0.1:81:81"
            - "80:80"
        volumes:
            - ./data:/data
            - ./letsencrypt:/etc/letsencrypt
        networks:
            - web_proxy

        extra_hosts:
            - "host.docker.internal:host-gateway"

networks:
    web_proxy:
        name: web_proxy
        driver: bridge

启动：

docker compose up -d
docker ps --filter name=nginx-proxy-manager

这里把 NPM 管理后台端口绑定到 127.0.0.1:81，公网不能直接访问，更安全。需要登录 NPM 管理后台时，在本地电脑开 SSH 隧道：

ssh -L 8181:127.0.0.1:81 root@<SERVER_IP>

然后浏览器打开：

http://127.0.0.1:8181

首次登录后立刻修改 NPM 默认账号密码。

5. 让 Marzneshin 面板只监听 Docker 网关​

编辑：

nano /etc/opt/marzneshin/.env

设置：

UVICORN_HOST="172.17.0.1"
UVICORN_PORT=8000

重启 Marzneshin：

cd /etc/opt/marzneshin
docker compose up -d

检查监听：

ss -tulpen | grep -E '(:8000|:80|:443)'

理想结果：

0.0.0.0:80      -> NPM
0.0.0.0:443     -> NPM
172.17.0.1:8000 -> Marzneshin 面板

此时公网 http://<SERVER_IP>:8000 应该访问不到，这是安全设计。

6. 在 NPM 中创建 Marzneshin 面板代理​

进入 NPM 后创建 Proxy Host。

Details​

Domain Names: <PROXY_DOMAIN>
Scheme: http
Forward Hostname / IP: 172.17.0.1
Forward Port: 8000
Cache Assets: 可开启
Block Common Exploits: 开启
Websockets Support: 开启

SSL​

Request a new SSL Certificate: 开启
Force SSL: 开启
HTTP/2 Support: 可按需开启
Email: 你的邮箱
I Agree: 勾选

保存后访问：

https://<PROXY_DOMAIN>/dashboard/

如果能看到登录页，面板反代完成。

7. 创建 VLESS WebSocket 入站​

进入 Marzneshin 面板，创建一个入站。核心目标是：

协议：vless
传输：ws
监听地址：172.17.0.1
监听端口：2087
WebSocket Path：<WS_PATH>

注意：这里的 Xray 后端不需要自己处理 TLS。TLS 由 NPM 在 443 端口终止，NPM 再把 WebSocket 请求转发到 172.17.0.1:2087。

推荐入站概念配置：

Tag / Name: vless WS
Protocol: vless
Network: ws
Listen: 172.17.0.1
Port: 2087
Path: <WS_PATH>
TLS: none / disabled

再创建 Host，告诉客户端应该怎么连：

Address: <PROXY_DOMAIN>
Port: 443
Protocol: vless
Network: ws
Path: <WS_PATH>
Security: tls
SNI: <PROXY_DOMAIN>
Host: <PROXY_DOMAIN>
Fingerprint: chrome

保存后检查监听：

ss -tulpen | grep 2087

理想结果：

172.17.0.1:2087 -> xray

8. 在 NPM 中添加 WebSocket 转发路径​

编辑 <PROXY_DOMAIN> 这个 Proxy Host，添加 Custom Location：

Location: <WS_PATH>
Scheme: http
Forward Hostname / IP: 172.17.0.1
Forward Port: 2087

在这个 location 的高级配置里加入：

proxy_set_header Host $host;
proxy_set_header X-Forwarded-Scheme $scheme;
proxy_set_header X-Forwarded-Proto  $scheme;
proxy_set_header X-Forwarded-For    $remote_addr;
proxy_set_header X-Real-IP          $remote_addr;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_http_version 1.1;
proxy_read_timeout 3600s;
proxy_send_timeout 3600s;

保存后，NPM 生成的效果大致类似：

location <WS_PATH> {
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Scheme $scheme;
    proxy_set_header X-Forwarded-Proto  $scheme;
    proxy_set_header X-Forwarded-For    $remote_addr;
    proxy_set_header X-Real-IP          $remote_addr;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $http_connection;
    proxy_http_version 1.1;
    proxy_read_timeout 3600s;
    proxy_send_timeout 3600s;
    proxy_pass http://172.17.0.1:2087;
}

9. 创建服务和用户​

在 Marzneshin 中：

1. 创建 Service，例如 <SERVICE_NAME>。
2. 勾选刚才创建的 vless WS 入站。
3. 创建用户，例如 <USERNAME>。
4. 让用户绑定到 <SERVICE_NAME> 服务。

用户订阅链接形如：

https://<PROXY_DOMAIN>/sub/<USERNAME>/<USER_KEY>

不要公开 <USER_KEY>。

10. 让 Clash / Mihomo 订阅自带分流规则​

Marzneshin 支持自定义 Clash 模板，但当前版本底层的 v2share 会在渲染时把模板里的 rules 清空。所以需要一个很小的 Python 补丁，让模板里的规则能够保留下来，同时把 Marzneshin 生成的节点填入代理组。

创建目录：

mkdir -p /var/lib/marzneshin/templates
mkdir -p /var/lib/marzneshin/patches

写入 /var/lib/marzneshin/patches/sitecustomize.py：

import random

import yaml

from v2share.clash import ClashConfig


PROXY_MARKER = "__MARZNESHIN_PROXIES__"


def _ordered_configs(configs, sort=True, shuffle=False):
    if shuffle:
        return random.sample(configs, len(configs))
    if sort:
        return sorted(configs, key=lambda config: config.weight)
    return configs


def _expand_group_proxies(group, remarks):
    proxies = group.get("proxies")
    if proxies == PROXY_MARKER:
        group["proxies"] = remarks
        return True

    if not isinstance(proxies, list):
        return False

    expanded = []
    found = False
    for proxy in proxies:
        if proxy == PROXY_MARKER:
            expanded.extend(remarks)
            found = True
        else:
            expanded.append(proxy)

    if found:
        group["proxies"] = expanded
    return found


def render_with_template_rules(self, sort=True, shuffle=False):
    configs = _ordered_configs(self._configs, sort=sort, shuffle=shuffle)

    proxies, remarks = [], []
    for proxy in configs:
        proxies.append(self._get_node(proxy))
        remarks.append(proxy.remark)

    result = yaml.safe_load(self.template_data) or {}
    result["proxies"] = proxies
    result.setdefault("rules", [])

    groups = result.get("proxy-groups") or []
    marker_found = False
    for group in groups:
        marker_found = _expand_group_proxies(group, remarks) or marker_found

    if groups and not marker_found:
        groups[0]["proxies"] = remarks

    return yaml.safe_dump(result, sort_keys=False, allow_unicode=True)


ClashConfig.render = render_with_template_rules

写入 /var/lib/marzneshin/templates/clash.yml。下面的模板使用自己的域名反代规则文件：

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false
unified-delay: true
tcp-concurrent: true

profile:
    store-selected: true
    store-fake-ip: true

proxy-groups:
    - name: Automatic
      type: url-test
      url: http://www.gstatic.com/generate_204
      interval: 300
      tolerance: 50
      lazy: true
      proxies:
          - __MARZNESHIN_PROXIES__

    - name: Proxy
      type: select
      proxies:
          - Automatic
          - __MARZNESHIN_PROXIES__
          - DIRECT

rule-providers:
    reject:
        type: http
        behavior: domain
        format: yaml
        url: https://<PROXY_DOMAIN>/rules/reject.txt
        proxy: DIRECT
        path: ./ruleset/reject.yaml
        interval: 86400
    private:
        type: http
        behavior: domain
        format: yaml
        url: https://<PROXY_DOMAIN>/rules/private.txt
        proxy: DIRECT
        path: ./ruleset/private.yaml
        interval: 86400
    icloud:
        type: http
        behavior: domain
        format: yaml
        url: https://<PROXY_DOMAIN>/rules/icloud.txt
        proxy: DIRECT
        path: ./ruleset/icloud.yaml
        interval: 86400
    apple:
        type: http
        behavior: domain
        format: yaml
        url: https://<PROXY_DOMAIN>/rules/apple.txt
        proxy: DIRECT
        path: ./ruleset/apple.yaml
        interval: 86400
    google:
        type: http
        behavior: domain
        format: yaml
        url: https://<PROXY_DOMAIN>/rules/google.txt
        proxy: DIRECT
        path: ./ruleset/google.yaml
        interval: 86400
    proxy:
        type: http
        behavior: domain
        format: yaml
        url: https://<PROXY_DOMAIN>/rules/proxy.txt
        proxy: DIRECT
        path: ./ruleset/proxy.yaml
        interval: 86400
    direct:
        type: http
        behavior: domain
        format: yaml
        url: https://<PROXY_DOMAIN>/rules/direct.txt
        proxy: DIRECT
        path: ./ruleset/direct.yaml
        interval: 86400
    gfw:
        type: http
        behavior: domain
        format: yaml
        url: https://<PROXY_DOMAIN>/rules/gfw.txt
        proxy: DIRECT
        path: ./ruleset/gfw.yaml
        interval: 86400
    tld-not-cn:
        type: http
        behavior: domain
        format: yaml
        url: https://<PROXY_DOMAIN>/rules/tld-not-cn.txt
        proxy: DIRECT
        path: ./ruleset/tld-not-cn.yaml
        interval: 86400
    lancidr:
        type: http
        behavior: ipcidr
        format: yaml
        url: https://<PROXY_DOMAIN>/rules/lancidr.txt
        proxy: DIRECT
        path: ./ruleset/lancidr.yaml
        interval: 86400
    cncidr:
        type: http
        behavior: ipcidr
        format: yaml
        url: https://<PROXY_DOMAIN>/rules/cncidr.txt
        proxy: DIRECT
        path: ./ruleset/cncidr.yaml
        interval: 86400
    telegramcidr:
        type: http
        behavior: ipcidr
        format: yaml
        url: https://<PROXY_DOMAIN>/rules/telegramcidr.txt
        proxy: DIRECT
        path: ./ruleset/telegramcidr.yaml
        interval: 86400

rules:
    - RULE-SET,private,DIRECT
    - RULE-SET,lancidr,DIRECT,no-resolve
    - RULE-SET,reject,REJECT
    - DOMAIN-SUFFIX,openai.com,Proxy
    - DOMAIN-SUFFIX,chatgpt.com,Proxy
    - DOMAIN-SUFFIX,oaistatic.com,Proxy
    - DOMAIN-SUFFIX,oaiusercontent.com,Proxy
    - DOMAIN-SUFFIX,anthropic.com,Proxy
    - DOMAIN-SUFFIX,claude.ai,Proxy
    - RULE-SET,telegramcidr,Proxy,no-resolve
    - RULE-SET,google,Proxy
    - RULE-SET,gfw,Proxy
    - RULE-SET,proxy,Proxy
    - RULE-SET,icloud,DIRECT
    - RULE-SET,apple,DIRECT
    - RULE-SET,direct,DIRECT
    - GEOSITE,cn,DIRECT
    - GEOIP,CN,DIRECT,no-resolve
    - RULE-SET,cncidr,DIRECT,no-resolve
    - RULE-SET,tld-not-cn,Proxy
    - MATCH,Proxy

启用模板和补丁。编辑 /etc/opt/marzneshin/.env，追加：

CUSTOM_TEMPLATES_DIRECTORY="/var/lib/marzneshin/templates/"
CLASH_SUBSCRIPTION_TEMPLATE="/var/lib/marzneshin/templates/clash.yml"
PYTHONPATH="/var/lib/marzneshin/patches"

重启：

cd /etc/opt/marzneshin
docker compose up -d marzneshin

11. 修正 Clash Verge / Mihomo 的订阅识别规则​

有些客户端的 User-Agent 是 Clash-Verge/2.0，原默认规则可能因为大小写或写法没有命中 clash-meta，导致回落到 classic Clash。classic Clash 不支持 VLESS，订阅里会出现 proxies: []。

可以在 Marzneshin 面板的订阅设置里把规则调整成：

(?i)^(clash[ .-]?verge|clash[ .-]?meta|mihomo) -> clash-meta
(?i)^(clash|stash)                             -> clash

如果直接用命令修改 SQLite 中的订阅设置，可以执行：

docker exec marzneshin-marzneshin-1 sh -lc 'python - << "PY"
from copy import deepcopy
from sqlalchemy.orm.attributes import flag_modified
from app.db import SessionLocal
from app.db.models import Settings

session = SessionLocal()
settings = session.query(Settings).first()
subscription = deepcopy(settings.subscription)
rules = subscription.get("rules", [])

new_rules = []
inserted_meta = False
inserted_clash = False
for rule in rules:
    result = rule.get("result", "")
    if result == "clash-meta" and not inserted_meta:
        new_rules.append({"pattern": "(?i)^(clash[ .-]?verge|clash[ .-]?meta|mihomo)", "result": "clash-meta"})
        inserted_meta = True
        continue
    if result == "clash" and not inserted_clash:
        new_rules.append({"pattern": "(?i)^(clash|stash)", "result": "clash"})
        inserted_clash = True
        continue
    new_rules.append(rule)

if not inserted_meta:
    new_rules.insert(0, {"pattern": "(?i)^(clash[ .-]?verge|clash[ .-]?meta|mihomo)", "result": "clash-meta"})
if not inserted_clash:
    new_rules.insert(1, {"pattern": "(?i)^(clash|stash)", "result": "clash"})

subscription["rules"] = new_rules
settings.subscription = subscription
flag_modified(settings, "subscription")
session.commit()
print(subscription["rules"][:3])
PY'

12. 用 NPM 反代规则文件​

目标是让客户端访问：

https://<PROXY_DOMAIN>/rules/google.txt

实际由 NPM 去请求：

https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/google.txt

这样客户端只需要能访问你的域名，不必直接访问 GitHub 或 jsDelivr。我们只放行固定规则文件名，不做开放代理。

创建 NPM 自定义配置目录：

mkdir -p /home/projects/nginx/data/nginx/custom

写入 /home/projects/nginx/data/nginx/custom/server_proxy.conf：

location ~ ^/rules/(reject|private|icloud|apple|google|proxy|direct|gfw|tld-not-cn|lancidr|cncidr|telegramcidr)\.txt$ {
    if ($host != "<PROXY_DOMAIN>") {
        return 404;
    }

    resolver 1.1.1.1 8.8.8.8 valid=300s ipv6=off;

    set $rules_host "cdn.jsdelivr.net";
    set $rules_name $1;

    proxy_ssl_server_name on;
    proxy_ssl_name $rules_host;
    proxy_set_header Host $rules_host;
    proxy_set_header User-Agent "nginx-proxy-manager-rules-proxy";
    proxy_set_header Accept "*/*";

    proxy_buffering on;
    proxy_read_timeout 60s;
    proxy_send_timeout 60s;

    proxy_hide_header Access-Control-Allow-Origin;
    add_header Access-Control-Allow-Origin "*" always;
    add_header Cache-Control "public, max-age=3600" always;

    proxy_pass https://$rules_host/gh/Loyalsoldier/clash-rules@release/$rules_name.txt;
}

重要细节：文件名必须是：

server_proxy.conf

不要命名成 server_proxy[.]conf。NPM 生成配置里的 include /data/nginx/custom/server_proxy[.]conf; 是 Nginx glob 写法，实际匹配的是 server_proxy.conf。

检查并 reload：

docker exec nginx-proxy-manager nginx -t
docker exec nginx-proxy-manager nginx -s reload

验证：

curl -ksS https://<PROXY_DOMAIN>/rules/google.txt | head

应该看到：

payload:
    - ...

13. 修复订阅名称显示异常​

有些客户端会把响应头：

content-disposition: attachment; filename="<USERNAME>"

解析成奇怪的名字，比如 \"<USERNAME>\。可以在 NPM 同一个 server_proxy.conf 中继续追加：

location ~ ^/sub/([^/]+)/[^/]+(/(sing-box|clash-meta|clash|xray|v2ray|links|wireguard))?/?$ {
    set $subscription_username $1;

    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Scheme $scheme;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_http_version 1.1;

    proxy_hide_header Content-Disposition;
    add_header Content-Disposition "attachment; filename=$subscription_username" always;

    proxy_pass http://172.17.0.1:8000;
}

完整的 /home/projects/nginx/data/nginx/custom/server_proxy.conf 应该同时包含 /rules/ 和 /sub/ 两段 location。

再次 reload：

docker exec nginx-proxy-manager nginx -t
docker exec nginx-proxy-manager nginx -s reload

验证订阅响应头：

KEY="<USER_KEY>"
curl -ksS -D - -o /dev/null -A 'Clash-Verge/2.0' "https://<PROXY_DOMAIN>/sub/<USERNAME>/$KEY"

应该看到：

Content-Disposition: attachment; filename=<USERNAME>

14. 客户端使用方式​

以 Clash Verge / Mihomo 为例：

1. 添加订阅链接：

   https://<PROXY_DOMAIN>/sub/<USERNAME>/<USER_KEY>
   

2. 刷新订阅。

3. 使用 Rule / 规则 模式。

4. TUN 可以开启。

5. 系统代理可以不开，TUN 会接管。

6. 在代理组里，把 Proxy 选成 Automatic。

预期结果：

Google / OpenAI / Telegram / GFW 列表：走代理
百度 / 国内 IP / 常见国内域名：直连
兜底 MATCH：走 Proxy

15. 验证命令​

检查服务运行：

docker ps --filter name=nginx-proxy-manager
docker ps --filter name=marzneshin

检查监听：

ss -tulpen | grep -E '(:80 |:443 |:8000 |:2087 |:81 )'

理想状态：

0.0.0.0:80        NPM
0.0.0.0:443       NPM
127.0.0.1:81      NPM 管理后台
172.17.0.1:8000   Marzneshin 面板
172.17.0.1:2087   Xray WS 后端

检查面板：

curl -ksS -o /dev/null -w '%{http_code}\n' https://<PROXY_DOMAIN>/dashboard/

应该返回：

200

检查规则文件反代：

for f in google proxy direct cncidr telegramcidr; do
  printf "$f "
  curl -ksS -o /dev/null -w '%{http_code} %{size_download}\n' "https://<PROXY_DOMAIN>/rules/$f.txt"
done

应该都是 200。

检查订阅是否是 Clash Meta 且带规则：

KEY="<USER_KEY>"
curl -ksS -A 'Clash-Verge/2.0' "https://<PROXY_DOMAIN>/sub/<USERNAME>/$KEY" > /tmp/subscription.yml

grep -E '^(mode:|proxies:|proxy-groups:|rule-providers:|rules:)' /tmp/subscription.yml
grep 'type: vless' /tmp/subscription.yml
grep 'RULE-SET,google,Proxy' /tmp/subscription.yml
grep 'MATCH,Proxy' /tmp/subscription.yml

应该能看到：

mode: rule
type: vless
RULE-SET,google,Proxy
MATCH,Proxy

16. 常见问题​

502 Bad Gateway​

最常见原因是 NPM 容器访问不到后端。

在这套方案里，不建议在 NPM 里把 Marzneshin 后端写成 <PROXY_DOMAIN>:8000，那会绕回公网域名，也可能形成错误转发。也不建议依赖 host.docker.internal，因为 NPM 生成的动态 proxy_pass 场景中，Nginx 的 resolver 不一定按 /etc/hosts 解析它。

推荐固定写：

172.17.0.1:8000
172.17.0.1:2087

延迟测试正常，但 Google 打不开​

这通常不是服务器节点问题，而是客户端分流规则问题。

如果全局模式可以打开 Google，规则模式打不开，说明订阅没有正确带规则，或者规则源下载失败。检查：

curl -ksS https://<PROXY_DOMAIN>/rules/google.txt | head

以及客户端里规则源是否更新成功。

订阅里 proxies: []​

大概率是客户端 User-Agent 没匹配到 clash-meta，回落到了 classic Clash。VLESS 需要 Clash Meta / Mihomo。检查订阅规则：

(?i)^(clash[ .-]?verge|clash[ .-]?meta|mihomo) -> clash-meta

NPM 自定义配置不生效​

确认文件名：

ls -l /home/projects/nginx/data/nginx/custom/server_proxy.conf

然后：

docker exec nginx-proxy-manager nginx -T | grep -n 'location ~ \^/rules' -A 30

如果看不到 /rules/ location，说明 include 没匹配到。

升级 Marzneshin 后订阅规则丢失​

本文的补丁通过：

PYTHONPATH="/var/lib/marzneshin/patches"

挂载在 /var/lib/marzneshin，不会因为容器重建丢失。但如果 Marzneshin 后续底层生成逻辑变动，建议升级后重新验证：

curl -ksS -A 'Clash-Verge/2.0' "https://<PROXY_DOMAIN>/sub/<USERNAME>/<USER_KEY>" | grep -E 'RULE-SET|type: vless|mode: rule'

17. 当前最终文件清单​

/etc/opt/marzneshin/docker-compose.yml
/etc/opt/marzneshin/.env
/var/lib/marzneshin/templates/clash.yml
/var/lib/marzneshin/patches/sitecustomize.py
/home/projects/nginx/docker-compose.yml
/home/projects/nginx/data/nginx/custom/server_proxy.conf

最终公网只需要开放：

80/tcp
443/tcp
22/tcp  # SSH，建议限制来源 IP 或改用密钥

18. 参考资料​

• Marzneshin 官方基础安装文档
• Marzneshin 官方 Nginx 反代文档
• Docker Compose 官方文档
• Loyalsoldier Clash 规则

但排查日志后发现，真正的问题并不是“微信走了代理”，而是 Clash 中开启 IPv6 后，让微信尝试了一条当前网络环境不可达的 IPv6 路径。

现象​

开启 Clash TUN 模式后：

• 微信文字消息基本正常
• 接收和发送图片明显变慢
• 关闭 Clash 中的 IPv6 后，微信图片恢复正常

排查过程​

先查看 Clash / Mihomo 的规则和连接日志。

配置中微信相关进程已经被明确设置为直连：

- PROCESS-NAME,Weixin.exe,DIRECT
- PROCESS-NAME,WeixinUpdate.exe,DIRECT
- PROCESS-NAME,WeChatAppEx.exe,DIRECT
- PROCESS-NAME,WeixinExt.exe,DIRECT

随后在微信接收一张图片时，对比 Mihomo 日志，发现新增记录类似这样：

[TCP] dial DIRECT (match ProcessName/Weixin.exe)
Weixin.exe --> [240e:xxxx:xxxx::xxxx]:443
error: connect failed: dial tcp [240e:xxxx:xxxx::xxxx]:443:
A socket operation was attempted to an unreachable network.

关键信息有三个：

DIRECT
ProcessName/Weixin.exe
IPv6 unreachable network

也就是说，微信并没有走代理，而是命中了 DIRECT 规则。但它尝试访问腾讯/微信的 IPv6 地址时，当前网络环境下这条 IPv6 路径不可达，于是发生反复重试，最终造成图片收发很慢。

真正原因​

问题不是：

• 微信图片走了代理
• 代理服务器太慢
• 微信服务器慢

更准确的原因是：

Clash / Mihomo 中开启 IPv6 后，微信拿到了 IPv6 目标地址，并尝试直连；但当前 TUN / 网络环境无法真正访问这些 IPv6 地址，于是连接失败、重试、回落，造成明显延迟。

这是一种“看起来支持 IPv6，但实际路径不可达”的情况。

解决方式​

在 Clash / Mihomo 中关闭 IPv6：

ipv6: false

dns:
    ipv6: false

然后重启 Clash 内核。

注意，这里说的是关闭 Clash / Mihomo 内部的 IPv6 支持，不是去 Windows 网卡里全局禁用 IPv6。

关闭 Clash IPv6 会有什么影响？​

关闭后，Clash 通常不再处理 IPv6 目标地址，也不会主动返回 IPv6 DNS 结果。大多数应用会回落到 IPv4。

影响一般是：

• IPv4 代理规则仍然正常工作
• 大多数网站和 App 不受影响
• 少数 IPv6-only 服务可能无法访问
• 如果某些服务 IPv6 路径原本更优，可能失去这部分优势
• 但在当前网络 IPv6 不通的情况下，关闭反而更稳定

代理本身是否支持 IPv6？​

不能只看代理节点入口 IP 来判断。

即使代理服务器入口是 IPv4，比如：

104.xxx.xxx.xxx:4431

它也可能支持代理 IPv6 目标地址。是否支持取决于：

• 节点服务器是否有 IPv6 出站能力
• 代理协议和服务端配置是否支持
• Clash/Mihomo 是否开启 IPv6 处理

在这次问题里，微信本身命中的是 DIRECT，所以重点并不是“节点是否支持 IPv6”，而是“微信直连 IPv6 不可达”。

总结​

这次微信图片慢的核心链路是：

Clash 开启 IPv6
        ↓
微信拿到 IPv6 地址
        ↓
微信按规则 DIRECT 直连
        ↓
当前网络/TUN 环境 IPv6 不可达
        ↓
连接失败、重试、回落
        ↓
收发图片变慢

关闭 Clash 中的 IPv6 后，微信更早走 IPv4，绕过不可达的 IPv6 路径，问题解决。

如果你也遇到 Clash TUN 模式下微信、QQ、国内 App 图片或资源加载很慢，可以优先检查 Mihomo 日志中是否存在类似：

DIRECT
IPv6
unreachable network

如果有，那么关闭 Clash / Mihomo 的 IPv6 很可能就是最直接的解决办法。

在开启 TUN 模式或系统代理模式时，部分应用（如微信、Radmin VPN）可能出现：

• 文件传输缓慢或失败
• 局域网通信异常
• VPN 无法建立连接

本文提供一套通用方案，使指定应用绕过 Clash Verge 代理。

步骤 1：配置 TUN 排除进程​

打开「订阅」→「全局扩展覆写配置」，覆盖粘贴：

# Profile Enhancement Merge Template for Clash Verge

profile:
    store-selected: true

# ✅ 关键：让 Radmin VPN 不被 TUN 接管
tun:
    exclude-process:
        - AnyDesk.exe
        - WeChatAppEx.exe
        - WeixinUpdate.exe
        - Weixin.exe
        - WetypeInstaller.exe
        - WeixinExt.exe
        - RvRvpnGui.exe
        - RvControlSvc.exe
        - Radmin.exe
        - drvinst.exe
        - RvFwHelper.exe
        - RvGuiStarter.exe

👉 作用：这些进程不会被 TUN 模式接管

步骤 2：添加规则强制直连​

打开「全局扩展脚本」，覆盖粘贴：

// Define main function (script entry)

function main(config, profileName) {
    // 为所有代理节点添加或设置 'udp: true'
    if (config.proxies) config.proxies.forEach(proxy => (proxy.udp = true))

    config.rules ??= []

    // 保留原有的添加域名规则的逻辑
    const name = config["proxy-groups"]?.at(0)?.name

    const excludeProcesses = [
        "AnyDesk.exe",
        "WeChatAppEx.exe",
        "WeixinUpdate.exe",
        "Weixin.exe",
        "WetypeInstaller.exe",
        "WeixinExt.exe",
        "RvRvpnGui.exe",
        "RvControlSvc.exe",
        "Radmin.exe",
        "drvinst.exe",
        "RvFwHelper.exe",
        "RvGuiStarter.exe",
    ]

    if (name) {
        config.rules.unshift(`DOMAIN-SUFFIX,claude.ai,${name}`)
        config.rules.unshift(`DOMAIN-SUFFIX,claude.com,${name}`)
        config.rules.unshift(`IP-CIDR,26.0.0.0/8,DIRECT`)
        excludeProcesses.forEach(item => config.rules.unshift(`PROCESS-NAME,${item},DIRECT`))
    }

    return config
}

👉 作用：

• 强制指定进程走直连
• 即使切换到“代理模式”仍然生效

步骤 3（可选）：调整 DNS 模式​

打开「设置」→「DNS 覆写」，将：

• fake-ip → redir-host

👉 适用于以下情况：

• 微信传文件异常
• 局域网通信不稳定

⚠️ 注意：

• 此步骤为可选项
• 如果修改后出现网络异常，可以恢复为 fake-ip

验证是否生效​

可以通过以下方式确认：

1. 测试 Radmin VPN​

ping 26.x.x.x

应正常通信。

2. 查看 Clash 日志​

在日志中应看到：

26.x.x.x → DIRECT

原理说明​

本方案基于三点：

1. tun.exclude-process

   • 控制流量是否进入 Clash（入口）

2. PROCESS-NAME,...,DIRECT

   • 控制流量走直连（出口）

3. IP-CIDR,26.0.0.0/8,DIRECT

   • 确保 Radmin VPN 内网流量不被代理

总结​

• TUN 排除：避免应用被接管
• 规则直连：保证任何模式下都不走代理
• DNS 调整：作为兼容性优化手段

通过以上配置，可以实现 Clash Verge 与微信、Radmin VPN 等应用的稳定共存。

function get(value: number[] = []) {
    return value
}

const a = get()
const b = get()

console.log(a === b)

结果是 false，所以函数的默认参数值是动态创建的。

同理，解构赋值也是动态创建的：

interface Info {
    data?: number[]
}

const info: Info = {}

function getData({ data = [] }: Info) {
    return data
}

const c = getData(info)
const d = getData(info)

console.log(c === d)

结果是 false，所以解构赋值也是动态创建的。

import { FC, useState } from "react"

import { useQuery } from "@tanstack/react-query"

async function getData() {
    return Promise.resolve(123456)
}

const Page: FC = () => {
    const [count, setCount] = useState(0)

    const { data } = useQuery({
        queryKey: ["get-data"],
        queryFn: getData,
        select: () => Date.now(),
    })

    return (
        <div>
            <div>now: {data}</div>
            <div>count: {count}</div>
            <div>
                <button onClick={() => setCount(count + 1)}>add</button>
            </div>
        </div>
    )
}

export default Page

当然我的 soda-tanstack-query 也是可以享受这个优化的。

UIMessage​

UIMessage 是 AI SDK 中的消息类型，是最核心的内容。

/**
The data types that can be used in the UI message for the UI message data parts.
 */
type UIDataTypes = Record<string, unknown>

type UITools = Record<string, UITool>

/**
AI SDK UI Messages. They are used in the client and to communicate between the frontend and the API routes.
 */
interface UIMessage<METADATA = unknown, DATA_PARTS extends UIDataTypes = UIDataTypes, TOOLS extends UITools = UITools> {
    /**
  A unique identifier for the message.
     */
    id: string
    /**
  The role of the message.
     */
    role: "system" | "user" | "assistant"
    /**
  The metadata of the message.
     */
    metadata?: METADATA
    /**
  The parts of the message. Use this for rendering the message in the UI.
  
  System messages should be avoided (set the system prompt on the server instead).
  They can have text parts.
  
  User messages can have text parts and file parts.
  
  Assistant messages can have text, reasoning, tool invocation, and file parts.
     */
    parts: Array<UIMessagePart<DATA_PARTS, TOOLS>>
}

UIMessage 接受三个泛型参数：

• METADATA：消息的元数据
• DATA_PARTS：消息的数据部分
• TOOLS：消息的工具

以下使我们创建的一个定义消息类型 MyUIMessage

export interface Metadata {
    conversationId: string
    messageId: string
    modelIdSnapshot: string
    usedTokens: number
}

// 由于 extends Record<string, unknown> 的限制，DataParts 不能是接口，必须是类型
export type DataParts = {
    timestamp: number
}

export type MyUIMessage = UIMessage<Metadata, DataParts>

METADATA​

metadata 就是消息的元数据，每一条消息（目前来看只有响应的消息）都可以有 metadata 属性，metadata 是附加在消息级别的自定义信息，用于描述消息本身的属性，而不是消息内容的一部分，我们可以使用 metadata 来传递一些额外的信息，比如当前的会话 id。

特点：

• 附加在 message.metadata 对象上
• 通过 toUIMessageStreamResponse 中的 messageMetadata 回调发送
• 描述整个消息的属性信息
• 持久化在消息历史中

适用场景:

• 适合存储时间戳、模型信息、token 使用量、用户上下文等消息级别的描述性信息

使用实例：

// 服务端
return result.toUIMessageStreamResponse<MyUIMessage>({
    messageMetadata: ({ part }) => {
        if (part.type === "start") {
            return {
                conversationId: "a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11",
                messageId: "6ec0bd7f-11c0-43da-975e-2a8ad9ebae0b",
                modelIdSnapshot: "GPT-5.2",
                usedTokens: 0,
            }
        }

        // 你可以选择更新整个 metadata
        if (part.type === "text") {
            // 由于 metadata 并不限于对象类型，所以并不支持局部更新
            return {
                conversationId: "a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11",
                messageId: "6ec0bd7f-11c0-43da-975e-2a8ad9ebae0b",
                modelIdSnapshot: "GPT-5.2",
                usedTokens: 1,
            }
        }
    },
})

// 客户端访问
console.log(message.metadata)

原文地址：Gemini 提示词设计指南，以下内容均为 Claude 4.5 sonnet 翻译

提示词设计是创建提示词（即自然语言请求）的过程，用于引导语言模型生成准确、高质量的响应。

本页面介绍基本概念、策略和最佳实践，帮助您开始设计提示词，以充分发挥 Gemini AI 模型的能力。

注意: 提示词工程是一个迭代过程。这些指南和模板只是起点。请根据您的具体用例和观察到的模型响应进行实验和改进。

特定主题的提示词指南​

寻找更具体的提示词策略？请查看我们的其他提示词指南：

• 使用媒体文件进行提示
• 使用 Imagen 和 Gemini 原生图像生成进行图像生成提示
• 视频生成提示

您还可以在提示词库中找到其他示例提示词，该库旨在交互式展示本指南中共享的许多概念。

清晰具体的指令​

定制模型行为的有效且高效的方法是提供清晰具体的指令。指令可以是问题形式、分步任务，或者像描述用户体验和思维方式一样复杂。

输入​

输入是提示词中的必需文本，您希望模型对其提供响应。输入可以是模型回答的问题（问题输入）、模型执行的任务（任务输入）、模型操作的实体（实体输入）或模型完成或继续的部分输入（完成输入）。

部分输入完成​

生成式语言模型的工作方式类似于高级自动补全工具。当您提供部分内容时，模型可以提供其余内容或它认为是该内容的延续作为响应。在这样做时，如果您包含任何示例或上下文，模型可以将这些示例或上下文考虑在内。

以下示例提供了带有指令和实体输入的提示词：

提示词：

对于给定的订单，返回一个 JSON 对象，该对象包含 cheeseburger、hamburger、fries 或 drink 字段，值为数量。
订单：一个汉堡和一杯饮料。

响应：

{
  "cheeseburger": 0,
  "hamburger": 1,
  "fries": 0,
  "drink": 1
}

虽然模型按提示执行了，但用自然语言写出指令有时可能具有挑战性，并且很多内容留给模型解释。例如，餐厅菜单可能包含许多项目。为了减小 JSON 响应的大小，您可能希望省略未订购的项目。在这种情况下，您可以给出一个示例和响应前缀，让模型完成它：

提示词：

有效字段为 cheeseburger、hamburger、fries 和 drink。

订单：给我一个芝士汉堡和薯条
输出：

```json
{
  "cheeseburger": 1,
  "fries": 1
}
```

订单：我要两个汉堡、一杯饮料和薯条。
输出：

响应：

{
  "hamburger": 2,
  "drink": 1,
  "fries": 1
}

注意 "cheeseburger" 从输出中排除了，因为它不是订单的一部分。

约束​

指定阅读提示词或生成响应的任何约束。您可以告诉模型做什么和不做什么。例如，您可以在提示词中指定摘要长度的约束：

提示词：

用一句话总结这段文字：

文字：量子计算机利用量子力学现象执行计算，速度比任何现代传统计算机快得多。在非常微小的尺度上，物质既表现为粒子又表现为波，量子计算使用专门的硬件来利用这种行为。量子设备的操作原理超出了经典物理学的范围。当大规模部署时，量子计算机可用于各种应用，例如：在网络安全中破解现有加密方法，同时帮助研究人员创建新方法；在气象学中开发更好的天气预报等。然而，当前最先进的量子计算机在很大程度上仍是实验性和不实用的。

响应：

量子计算机利用量子力学现象，执行计算的速度比传统计算机快得多，可用于网络安全和气象学等潜在应用，尽管它们目前在很大程度上仍是实验性和不实用的。

响应格式​

您可以给出指定响应格式的指令。例如，您可以要求响应格式化为表格、项目符号列表、电梯演讲、关键词、句子或段落。以下系统指令告诉模型在响应中更加对话化：

系统指令：

除非用户特别要求简洁的响应，否则所有问题都应详细全面地回答。

提示词：

在 2025 年销售 DVD 的企业，有什么聪明的做法？

响应：

由于数字流媒体和点播服务的压倒性主导地位，在 2025 年开始销售 DVD 的业务面临着重大挑战；因此，“聪明”的方法需要高度专业化的利基市场、超越光盘本身的强大价值主张，以及可能专注于社区或收藏家市场而不是主流消费。

以下是 2025 年聪明的 DVD 业务可能包含的内容：

1. 极端利基专业化：您无法与流媒体库竞争。您的业务必须专注于数字不容易或根本不提供的内容。这可能包括：
   * 绝版和稀有标题：寻找从未以数字方式发行或目前在主要流媒体平台上无法获得的电影或电视节目。
   ....

使用完成策略格式化响应​

完成策略也可以帮助格式化响应。以下示例提示模型创建论文大纲：

提示词：

创建一篇关于蜂鸟的论文大纲。

响应：

以下是关于蜂鸟的论文可能的大纲：

I. 引言
   A. 钩子：以关于蜂鸟的引人入胜的事实或描述开始（例如，它们的速度、彩虹色或微小的尺寸）。
   B. 背景：简要介绍蜂鸟——它们的分布（美洲）、它们作为独特鸟类的声誉。
   C. 论点陈述：陈述论文的主要观点，可以是关于蜂鸟的显著适应性、行为和生态重要性。

II. 外观和识别
   .....

提示词没有指定大纲的格式，模型为您选择了一种格式。要让模型返回特定格式的大纲，您可以添加代表大纲开始的文本，让模型根据您发起的模式完成它。

提示词：

创建一篇关于蜂鸟的论文大纲。

I. 引言
   *

响应：

好的，这是关于蜂鸟的论文大纲，从您提供的引言开始：

I. 引言
   * 钩子：以关于蜂鸟的引人入胜的事实或描述开始（例如，它们的速度、彩虹色或微小的尺寸）。
   * 背景：简要介绍蜂鸟——它们的分布（美洲）、它们作为独特鸟类的声誉及其一般特征。
   * 论点陈述：陈述论文的主要观点，重点关注使蜂鸟非凡的显著适应性、行为和生态意义。
   .....

零样本与少样本提示词​

您可以在提示词中包含示例，向模型展示正确的做法。模型尝试从示例中识别模式和关系，并在生成响应时应用它们。包含少量示例的提示词称为少样本提示词，而不提供示例的提示词称为零样本提示词。少样本提示词通常用于规范格式、措辞、范围或模型响应的一般模式。使用具体且多样化的示例帮助模型缩小焦点并生成更准确的结果。

我们建议始终在提示词中包含少样本示例。没有少样本示例的提示词可能效果较差。实际上，如果您的示例在显示手头任务方面足够清晰，您可以从提示词中删除指令。

以下零样本提示词要求模型选择最佳解释。

提示词：

请选择问题的最佳解释：

问题：雪是如何形成的？
解释 1：雪是在空气中的水蒸气在大气中冻结成冰晶时形成的，这些冰晶可以在大气中下降时结合并生长成雪花，并在地面上积累。
解释 2：水蒸气冻结成冰晶形成雪。

答案：

响应：

解释 1 是更好的解释，因为它提供了关于该过程的更多细节，包括冰晶如何在大气中下降时结合并生长成雪花。

如果您的用例要求模型产生简洁的响应，您可以在提示词中包含偏好简洁响应的示例。

以下提示词提供了两个显示偏好较短解释的示例。在响应中，您可以看到示例引导模型选择较短的解释（解释 2），而不是像之前那样选择较长的解释（解释 1）。

提示词：

以下是一些显示问题、解释和答案格式的示例：

问题：为什么天空是蓝色的？
解释 1：天空看起来是蓝色的，因为瑞利散射，这导致较短的蓝色波长的光比较长的红色波长更容易散射，使天空看起来是蓝色的。
解释 2：由于瑞利散射效应。
答案：解释 2

问题：地震的原因是什么？
解释 1：地壳中能量的突然释放。
解释 2：当构造板块突然滑动或断裂时会发生地震，导致能量释放，产生地震波，可以震动地面并造成损坏。
答案：解释 1

现在，根据上面的示例格式回答以下问题：

问题：雪是如何形成的？
解释 1：雪是在空气中的水蒸气在大气中冻结成冰晶时形成的，这些冰晶可以在大气中下降时结合并生长成雪花，并在地面上积累。
解释 2：水蒸气冻结成冰晶形成雪。

答案：

响应：

答案：解释 2

最佳示例数量​

像 Gemini 这样的模型通常可以使用少量示例识别模式，尽管您可能需要尝试在提示词中提供的示例数量以获得最佳结果。同时，如果您包含太多示例，模型可能会开始对示例的响应过度拟合。

模式与反模式​

使用示例向模型展示要遵循的模式比使用示例向模型展示要避免的反模式更有效。

❌ 负面模式：

示例：

不要以问题结束俳句：
俳句很有趣
一首简短而简单的诗
你不喜欢它们吗？

✅ 正面模式：

示例：

始终以断言结束俳句：
俳句很有趣
一首简短而简单的诗
写作的乐趣

一致的格式​

确保少样本示例的结构和格式相同，以避免产生不良格式的响应。在提示词中添加少样本示例的主要目标之一是向模型展示响应格式。因此，确保所有示例的格式一致至关重要，特别要注意 XML 标签、空格、换行符和示例分隔符。

添加上下文​

您可以在提示词中包含模型解决问题所需的指令和信息，而不是假设模型拥有所有必需的信息。这种上下文信息有助于模型理解您要求它做什么的约束和细节。

以下示例要求模型提供路由器的故障排除指导：

提示词：

我应该怎么做才能修复断开的 WiFi？
我的 Google WiFi 路由器上的灯是黄色的，缓慢闪烁。

响应：

Google WiFi 路由器上的黄色闪烁灯通常表示互联网连接有问题。以下是一些故障排除和修复问题的步骤：

1. 重启路由器和调制解调器：
   - 从电源插座拔下调制解调器，等待 30 秒。
   - 将调制解调器重新插入，等待它完全启动。
   - 拔下 Google WiFi 路由器，等待 30 秒。
   - 将 Google WiFi 路由器重新插入，等待它完全启动。
   .....

响应看起来像通用的故障排除信息，不特定于路由器或 LED 指示灯的状态。

要为特定路由器定制响应，您可以在提示词中添加路由器的故障排除指南作为上下文，供其在提供响应时参考。

提示词：

使用下面的文本回答问题。仅使用提供的文本进行响应。

问题：我应该怎么做才能修复断开的 WiFi？我的 Google WiFi 路由器上的灯是黄色的，缓慢闪烁。

文本：
颜色：缓慢脉动黄色
含义：存在网络错误。
处理方法：检查以太网电缆是否连接到路由器和调制解调器，并且两个设备都已打开。您可能需要重新拔插每个设备。

颜色：快速闪烁黄色
含义：您正在按住重置按钮并进行出厂重置。
处理方法：如果您继续按住重置按钮，大约 12 秒后，灯将变为稳定黄色。一旦变为稳定黄色，松开出厂重置按钮。

颜色：稳定黄色
含义：路由器正在进行出厂重置。
处理方法：这可能需要长达 10 分钟。完成后，设备将重置并开始脉动白色，让您知道它已准备好进行设置。

颜色：稳定红色
含义：出现问题。
处理方法：严重故障。出厂重置路由器。如果灯保持红色，请联系 WiFi 客户支持。

响应：

检查以太网电缆是否连接到路由器和调制解调器，并且两个设备都已打开。您可能需要重新拔插每个设备。

添加前缀​

前缀是您添加到提示词内容的单词或短语，可以根据您放置前缀的位置发挥多种作用：

• 输入前缀: 在输入中添加前缀向模型发出输入语义上有意义的部分的信号。例如，前缀 English: 和 French: 界定两种不同的语言。
• 输出前缀: 即使输出是由模型生成的，您也可以在提示词中为输出添加前缀。输出前缀为模型提供有关预期响应的信息。例如，输出前缀 JSON: 向模型发出信号，表明输出应为 JSON 格式。
• 示例前缀: 在少样本提示词中，向示例添加前缀提供标签，模型可以在生成输出时使用这些标签，这使得解析输出内容更容易。

在以下示例中，Text:是输入前缀，The answer is:是输出前缀。

提示词：

将文本分类为以下类别之一。
- large（大型）
- small（小型）

Text: Rhino
The answer is: large

Text: Mouse
The answer is: small

Text: Snail
The answer is: small

Text: Elephant
The answer is:

响应：

The answer is: large

将提示词分解为组件​

对于需要复杂提示词的用例，您可以通过将事物分解为更简单的组件来帮助模型管理这种复杂性。

1. 分解指令: 不要在一个提示词中包含许多指令，而是为每个指令创建一个提示词。您可以根据用户的输入选择要处理的提示词。

2. 链接提示词: 对于涉及多个顺序步骤的复杂任务，将每个步骤作为一个提示词，并按顺序链接提示词。在这个顺序链中，序列中一个提示词的输出成为下一个提示词的输入。序列中最后一个提示词的输出是最终输出。

3. 聚合响应: 聚合是指您想对数据的不同部分执行不同的并行任务，并聚合结果以产生最终输出。例如，您可以告诉模型对数据的第一部分执行一项操作，对其余数据执行另一项操作并聚合结果。

尝试模型参数​

您发送到模型的每个调用都包含控制模型如何生成响应的参数值。模型可以为不同的参数值生成不同的结果。尝试不同的参数值以获得任务的最佳值。不同模型可用的参数可能不同。最常见的参数如下：

1. 最大输出令牌数: 指定响应中可以生成的最大令牌数。一个令牌大约是四个字符。100 个令牌大约对应 60-80 个单词。

2. 温度: 温度控制令牌选择中的随机性程度。温度用于响应生成期间的采样，当应用 topP 和 topK 时发生。较低的温度适用于需要更确定性或更少开放式响应的提示词，而较高的温度可以导致更多样化或更有创意的结果。温度为 0 是确定性的，意味着始终选择最高概率的响应。

   注意: 使用 Gemini 3 模型时，我们强烈建议将 temperature 保持在默认值 1.0。更改温度（将其设置为 1.0 以下）可能会导致意外行为，例如循环或性能下降，特别是在复杂的数学或推理任务中。

3. topK: topK 参数改变模型如何选择令牌进行输出。topK 为 1 意味着所选令牌是模型词汇表中所有令牌中最可能的（也称为贪婪解码），而 topK 为 3 意味着使用温度从 3 个最可能的令牌中选择下一个令牌。对于每个令牌选择步骤，对具有最高概率的 topK 令牌进行采样。然后根据 topP 进一步过滤令牌，最后使用温度采样选择最终令牌。

4. topP: topP 参数改变模型如何选择令牌进行输出。从最可能到最不可能选择令牌，直到它们的概率之和等于 topP 值。例如，如果令牌 A、B 和 C 的概率分别为 0.3、0.2 和 0.1，topP 值为 0.5，则模型将使用温度选择 A 或 B 作为下一个令牌，并排除 C 作为候选。默认 topP 值为 0.95。

5. stop_sequences: 设置停止序列以告诉模型停止生成内容。停止序列可以是任何字符序列。尽量避免使用可能出现在生成内容中的字符序列。

提示词迭代策略​

提示词设计有时需要进行几次迭代，然后才能持续获得您想要的响应。本节提供有关迭代提示词时可以尝试的一些事项的指导：

1. 使用不同的措辞: 在提示词中使用不同的词或措辞通常会从模型中产生不同的响应，即使它们的意思相同。如果您没有从提示词中获得预期的结果，请尝试重新措辞。

   版本 1：我如何烤馅饼？
   版本 2：建议一个馅饼的食谱。
   版本 3：有什么好的馅饼食谱？
   

2. 切换到类似任务: 如果您无法让模型遵循任务的指令，请尝试为实现相同结果的类似任务提供指令。

   此提示词告诉模型使用预定义类别对书籍进行分类：

   提示词：

   《奥德赛》属于哪个类别：
   惊悚片
   科幻
   神话
   传记
   

   响应：

   《奥德赛》属于**神话**类别。
   
   原因如下：
   * **神话:** 《奥德赛》讲述了奥德修斯的故事，他是希腊神话中的英雄，以及他在特洛伊战争后回家的旅程。它以希腊神话中常见的神、怪物和超自然事件为特色。
   .....
   

   响应是正确的，但模型没有保持在选项范围内。您还希望模型只用一个选项响应，而不是用完整的句子。在这种情况下，您可以将指令重新表述为多项选择题，并要求模型选择一个选项。

   提示词：

   多项选择题：以下哪个选项描述了《奥德赛》这本书？
   
   选项：
   - 惊悚片
   - 科幻
   - 神话
   - 传记
   

   响应：

   正确答案是神话。
   

3. 更改提示词内容的顺序: 提示词中内容的顺序有时会影响响应。尝试更改内容顺序，看看这如何影响响应。

   版本 1：
   [示例]
   [上下文]
   [输入]
   
   版本 2：
   [输入]
   [示例]
   [上下文]
   
   版本 3：
   [示例]
   [输入]
   [上下文]
   

后备响应​

后备响应是当提示词或响应触发安全过滤器时模型返回的响应。后备响应的示例是 "我无法帮助解决这个问题，因为我只是一个语言模型。"

如果模型以后备响应响应，请尝试提高温度。

要避免的事项​

• 避免依赖模型生成事实信息。
• 谨慎用于数学和逻辑问题。

Gemini 3​

Gemini 3 模型专为高级推理和指令遵循而设计。它们对直接、结构良好并清楚定义任务和任何约束的提示词反应最佳。对于 Gemini 3 的最佳结果，建议采用以下做法：

核心提示词原则​

• 精确直接: 清晰简洁地陈述您的目标。避免不必要或过度说服性的语言。
• 使用一致的结构: 使用清晰的分隔符来分隔提示词的不同部分。XML 样式标签（例如 <context>、<task>）或 Markdown 标题是有效的。在单个提示词中选择一种格式并始终如一地使用它。
• 定义参数: 明确解释任何模糊的术语或参数。
• 控制输出详细程度: 默认情况下，Gemini 3 提供直接有效的答案。如果您需要更对话化或详细的响应，您必须在指令中明确请求。
• 连贯处理多模态输入: 使用文本、图像、音频或视频时，将它们视为同等级别的输入。确保您的指令根据需要清楚地引用每种模态。
• 优先考虑关键指令: 将基本行为约束、角色定义（角色）和输出格式要求放在系统指令或用户提示词的最开始。
• 为长上下文构建结构: 提供大量上下文（例如文档、代码）时，首先提供所有上下文。将您的具体指令或问题放在提示词的最后。
• 锚定上下文: 在大块数据之后，使用清晰的过渡短语来连接上下文和您的查询，例如 "基于以上信息..."

增强推理和规划​

您可以利用 Gemini 3 的高级思维能力，通过提示它在提供最终响应之前进行规划或自我批评来提高复杂任务的响应质量。

示例 - 明确规划：

在提供最终答案之前，请：
1. 将既定目标解析为不同的子任务。
2. 检查输入信息是否完整。
3. 创建结构化大纲以实现目标。

示例 - 自我批评：

在返回最终响应之前，请根据用户的原始约束检查您生成的输出。
1. 我是否回答了用户的*意图*，而不仅仅是他们的字面意思？
2. 语气是否符合所要求的角色？

结构化提示词示例​

使用标签或 Markdown 可帮助模型区分指令、上下文和任务。

XML 示例：

<role>
您是一个有用的助手。
</role>

<constraints>
1. 保持客观。
2. 引用来源。
</constraints>

<context>
[在此处插入用户输入 - 模型知道这是数据，而非指令]
</context>

<task>
[在此处插入具体的用户请求]
</task>

Markdown 示例：

# 身份
您是一名高级解决方案架构师。

# 约束
- 不允许使用外部库。
- 仅使用 Python 3.11+ 语法。

# 输出格式
返回单个代码块。

结合最佳实践的示例模板​

此模板捕获了使用 Gemini 3 进行提示的核心原则。请务必根据您的具体用例进行迭代和修改。

系统指令：

<role>
您是 Gemini 3，[插入领域，例如数据科学]的专业助手。
您精确、分析性强且坚持不懈。
</role>

<instructions>
1. **规划**：分析任务并创建分步计划。
2. **执行**：执行计划。
3. **验证**：根据用户的任务检查您的输出。
4. **格式化**：以请求的结构呈现最终答案。
</instructions>

<constraints>
- 详细程度：[指定 低/中/高]
- 语气：[指定 正式/随意/技术性]
</constraints>

<output_format>
按如下方式构建您的响应：
1. **执行摘要**：[简短概述]
2. **详细响应**：[主要内容]
</output_format>

用户提示词：

<context>
[在此处插入相关文档、代码片段或背景信息]
</context>

<task>
[在此处插入具体的用户请求]
</task>

<final_instruction>
记住在回答之前要逐步思考。
</final_instruction>

代理工作流​

对于深度代理工作流，通常需要特定的指令来控制模型如何推理、规划和执行任务。虽然 Gemini 提供了强大的通用性能，但复杂的代理通常需要您配置计算成本（延迟和令牌）与任务准确性之间的权衡。

在为代理设计提示词时，请考虑您可以在代理中引导的以下行为维度：

推理和策略​

配置模型在采取行动之前如何思考和规划。

• 逻辑分解: 定义模型必须多彻底地分析约束、先决条件和操作顺序。
• 问题诊断: 控制识别原因时的分析深度以及模型对溯因推理的使用。确定模型是应该接受最明显的答案还是探索复杂、不太可能的解释。
• 信息详尽性: 在分析每个可用策略和文档与优先考虑效率和速度之间进行权衡。

执行和可靠性​

配置代理如何自主操作和处理障碍。

• 适应性: 模型如何对新数据做出反应。确定它是应该严格遵守其初始计划，还是在观察结果与假设相矛盾时立即转向。
• 持久性和恢复: 模型尝试自我纠正错误的程度。高持久性会提高成功率，但会面临更高的令牌成本或循环风险。
• 风险评估: 评估后果的逻辑。明确区分低风险的探索性操作（读取）和高风险的状态更改（写入）。

交互和输出​

配置代理如何与用户通信和格式化结果。

• 歧义和权限处理: 定义何时允许模型做出假设，何时必须暂停执行以请求用户澄清或许可。
• 详细程度: 控制与工具调用一起生成的文本量。这决定了模型是向用户解释其操作还是在执行期间保持沉默。
• 精确性和完整性: 输出所需的保真度。指定模型是否必须解决每个边缘情况并提供确切数字，或者大致估计是否可以接受。

系统指令模板​

以下系统指令是一个示例，已经过研究人员评估，可以提高代理基准测试的性能，在这些基准测试中，模型必须遵守复杂的规则手册并与用户互动。它鼓励代理充当强大的推理者和规划者，在上述维度上强制执行特定行为，并要求模型在采取任何行动之前主动规划。

您可以调整此模板以适应您的特定用例约束。

您是一个非常强大的推理者和规划者。使用这些关键指令来构建您的计划、思想和响应。

在采取任何行动（工具调用*或*对用户的响应）之前，您必须主动、系统地、独立地规划和推理：

1) 逻辑依赖关系和约束：根据以下因素分析预期操作。按重要性顺序解决冲突：
    1.1) 基于策略的规则、强制性先决条件和约束。
    1.2) 操作顺序：确保采取操作不会阻止后续必要的操作。
        1.2.1) 用户可能以随机顺序请求操作，但您可能需要重新排序操作以最大化任务的成功完成。
    1.3) 其他先决条件（所需的信息和/或操作）。
    1.4) 明确的用户约束或偏好。

2) 风险评估：采取该操作的后果是什么？新状态会导致任何未来问题吗？
    2.1) 对于探索性任务（如搜索），缺少*可选*参数是低风险。**除非**您的`规则 1`（逻辑依赖关系）推理确定可选信息对于计划中的后续步骤是必需的，否则更倾向于使用可用信息调用工具，而不是询问用户。

3) 溯因推理和假设探索：在每个步骤中，确定遇到的任何问题最合乎逻辑和最可能的原因。
    3.1) 超越直接或明显的原因。最可能的原因可能不是最简单的，可能需要更深入的推断。
    3.2) 假设可能需要额外的研究。每个假设可能需要多个步骤来测试。
    3.3) 根据可能性对假设进行优先排序，但不要过早地丢弃不太可能的假设。低概率事件仍可能是根本原因。

4) 结果评估和适应性：先前的观察是否需要对您的计划进行任何更改？
    4.1) 如果您的初始假设被证伪，请根据收集的信息主动生成新假设。

5) 信息可用性：合并所有适用的和替代的信息来源，包括：
    5.1) 使用可用工具及其功能
    5.2) 所有策略、规则、检查清单和约束
    5.3) 先前的观察和对话历史
    5.4) 仅通过询问用户才能获得的信息

6) 精确性和基础：确保您的推理对每种确切的持续情况都极其精确和相关。
    6.1) 在引用信息时，通过引用确切的适用信息（包括策略）来验证您的声明。

7) 完整性：确保所有要求、约束、选项和偏好都详尽地纳入您的计划。
    7.1) 使用 #1 中的重要性顺序解决冲突。
    7.2) 避免过早结论：给定情况可能有多个相关选项。
        7.2.1) 要检查选项是否相关，请推理 #5 中的所有信息来源。
        7.2.2) 您可能需要咨询用户才能知道某事是否适用。不要在不检查的情况下假设它不适用。
    7.3) 查看 #5 中的适用信息来源，以确认哪些与当前状态相关。

8) 持久性和耐心：除非上述所有推理都已用尽，否则不要放弃。
    8.1) 不要因所花费的时间或用户沮丧而气馁。
    8.2) 这种持久性必须是智能的：对于*瞬态*错误（例如，请重试），您*必须*重试**除非已达到明确的重试限制（例如，最多 x 次尝试）**。如果达到这样的限制，您*必须*停止。对于*其他*错误，您必须更改策略或参数，而不是重复相同的失败调用。

9) 抑制您的响应：仅在完成上述所有推理后才采取行动。一旦您采取了行动，就无法收回。

生成模型的底层原理​

本节旨在回答这个问题 - 生成模型的响应中是否存在随机性，还是它们是确定性的？

简短的答案 - 两者都是。当您提示生成模型时，文本响应会分两个阶段生成。在第一阶段，生成模型处理输入提示词并生成可能接下来出现的令牌（单词）的概率分布。例如，如果您使用输入文本 "The dog jumped over the ..." 进行提示，生成模型将产生一系列可能的下一个单词：

[("fence", 0.77), ("ledge", 0.12), ("blanket", 0.03), ...]

这个过程是确定性的；每次输入相同的提示文本时，生成模型都会产生相同的分布。

在第二阶段，生成模型通过几种解码策略之一将这些分布转换为实际的文本响应。一个简单的解码策略可能是在每个时间步选择最可能的令牌。这个过程总是确定性的。但是，您可以选择通过对模型返回的分布进行随机采样来生成响应。这个过程将是随机的（随机的）。通过设置温度来控制此解码过程中允许的随机性程度。温度为 0 意味着只选择最可能的令牌，并且没有随机性。相反，高温度会在模型选择的令牌中注入高度的随机性，从而导致更意外、更令人惊讶的模型响应。对于 Gemini 3，建议不要更改默认温度 1.0 以避免意外结果。

后续步骤​

• 既然您对提示词设计有了更深入的了解，请尝试使用 Google AI Studio 编写自己的提示词
• 了解有关 Gemini 3 Pro Preview 模型的更多信息
• 要了解多模态提示，请参阅使用媒体文件进行提示。
• 要了解图像提示，请参阅 Imagen 提示指南
• 要了解视频提示，请参阅 Veo 提示指南

以下内容均为 Gemini 2.5 Pro 生成

当你在 TypeScript 中定义一个类 (class) 并希望一个函数只接受该类的 实例 时，你可能会遇到一个令人困惑的情况。

假设你有以下代码：

class Person {
    name: string

    constructor(name: string) {
        this.name = name
    }

    sayHello() {
        console.log(`Hello, my name is ${this.name}`)
    }
}

function get(a: Person) {
    a.sayHello()
}

// ✅ 没问题，这符合预期
get(new Person("Alice"))

// ❓ 咦？为什么这也行？！
get({ name: "Tom" })
// 错误: Property 'sayHello' is missing in type '{ name: string; }'
// but required in type 'Person'.

（注：在上面的基础示例中，如果 Person 类有 sayHello 方法，那么 { name: "Tom" } 会报错，因为它缺少该方法。但如果 Person 类只有 name 属性，代码就不会报错，这正是问题的核心。）

让我们用一个更简洁的例子来重现这个问题：

class Person {
    name: string

    constructor(name: string) {
        this.name = name
    }
}

function get(a: Person) {
    console.log(a.name)
}

// ✅ 传入实例
get(new Person("Alice"))

// ❌ 为什么这里不报错？
// 我传入了一个对象字面量，而不是 Person 的实例！
get({ name: "Tom" })

这到底是怎么回事？这其实是 TypeScript 的一个核心特性在起作用，它被称为 结构化类型（Structural Typing），也常被称作“鸭子类型”。

什么是结构化类型？​

TypeScript 在比较类型时，并不关心“你叫什么名字”（即名义类型，Nominal Typing），而只关心“你长什么样”（即结构化类型，Structural Typing）。

在上面的例子中：

1. 函数 get 期望一个类型为 Person 的参数。
2. Person 类型的 结构 被定义为：“一个拥有 string 类型 name 属性的对象”。
3. 我们传入的对象字面量 { name: "Tom" }，它的 结构 也是：“一个拥有 string 类型 name 属性的对象”。

由于两者结构兼容，TypeScript 编译器说：“看起来像一只鸭子，叫起来也像一只鸭子……那它就是一只鸭子。” 于是，编译通过了。

但这并不是我们想要的！我们希望 get 函数只接受通过 new Person(...) 创建的真实实例。那么，如何做到这一点呢？

解决方案：使用“私有品牌” (Private Branding)​

要强制实现名义类型（即严格限制为类的实例），最简单、最常用的技巧是给类添加一个私有成员。

这个私有成员就像一个独一无二的“品牌”标记，只有这个类和它的实例才能拥有。

让我们来修改 Person 类：

class Person {
    name: string

    // 👇 **这就是关键！**
    // 我们添加了一个私有的 "品牌" 属性
    private _brand!: void

    constructor(name: string) {
        this.name = name
    }
}

function get(a: Person) {
    console.log(a.name)
}

// ✅ 正确：传入 Person 的实例
get(new Person("Alice"))

// ❌ 错误：传入对象字面量
get({ name: "Tom" })

现在，当你尝试传入对象字面量时，TypeScript 编译器会立刻报错：

Argument of type { name: string; } is not assignable to parameter of type Person. Property _brand is missing in type { name: string; } but required in type Person.

为什么这样能行？

• new Person("Alice") 创建的实例，其类型签名中包含 private _brand: void。
• { name: "Tom" } 这个对象字面量，其类型签名中不包含 _brand 属性。

因为 private 成员是类结构签名的一部分，而对象字面量无法提供这个私有成员，所以 TypeScript 判定它们的结构不兼容，从而达到了我们的目的。

零运行时成本的“幽灵属性”​

你可能会问：“这个 _brand 属性会增加我运行时的开销吗？它会存在于我最终的 JavaScript 代码中吗？”

答案是：完全不会。

这正是这个技巧最巧妙的地方。让我们来分解这行代码：private _brand!: void;

1. private：这是一个 TypeScript 的访问修饰符。它只在编译时有效，用于类型检查。它会在编译成 JavaScript 时被完全擦除。
2. ! (非空断言)：这是在告诉 TypeScript：“你不用担心这个属性没被初始化，相信我。” 它只在编译时有效，用于“安抚”编译器，同样会被完全擦除。
3. : void：这是一个纯粹的类型注解。和所有 TypeScript 中的类型（如 :string, :number）一样，它会被完全擦除。

编译对比​

你的 TypeScript (TS)

class Person {
    name: string
    private _brand!: void

    constructor(name: string) {
        this.name = name
    }
}

编译后的 JavaScript (JS)

class Person {
    constructor(name) {
        this.name = name
        // 注意：_brand 在这里完全消失了！
    }
}

_brand 只是一个“幽灵属性”，它只存在于 TypeScript 的类型系统中，专门用来在编译时“品牌化”你的类。它对运行时的性能和内存占用没有任何影响。

总结​

• 问题：TypeScript 默认使用结构化类型，导致对象字面量可以匹配同结构的类。
• 目标：我们想强制使用名义类型，只接受类的真实实例。
• 解决方案：在类中添加一个 private 属性（如 private _brand!: void;）来进行“品牌化”。
• 优势：此方法零运行时成本，所有“品牌”标记都在编译为 JavaScript 时被擦除，只在 TypeScript 类型检查阶段发挥作用。

下次当你需要确保一个参数必须是某个类的实例时，试试这个“私有品牌”技巧吧！

以下内容均为 Gemini 2.5 Pro Deep Research 生成

如果你是一位 Clash 的进阶用户，你很可能遇到过这个经典难题：一套精心编写、在"规则模式"（系统代理）下完美运行的规则，在切换到功能强大的"TUN 模式"后却突然失效。本该走向代理的流量莫名其妙地选择了直连,让你只能盯着连接日志，对自己的配置产生怀疑。

这正是一次此类排错之旅的真实记录——一个多层次的问题，它始于 DNS，意外地转向了网络协议，最终以一个优雅的脚本方案画上句号。跟随本文，你将理解其背后深层的运行机制，并学会如何彻底征服 TUN 模式。

第一部分：消失的主机名悬案​

最初的问题非常明确。一位用户使用全局扩展脚本，在规则列表的顶端插入规则，以确保像 claude.ai 和 claude.com 这样的域名总是通过特定的代理分组。

脚本如下：

function main(config, profileName) {
    const name = config['proxy-groups']?.?.name;
    //...
    config.rules.unshift(`DOMAIN-SUFFIX,claude.ai,${name}`);
    config.rules.unshift(`DOMAIN-SUFFIX,claude.com,${name}`);
    //...
    return config;
}

在 规则模式 下，一切正常。但在 TUN 模式 下，访问 Claude 的连接却走向了 DIRECT。

根本原因：架构的鸿沟

这是关于 TUN 模式的第一个，也是最基础的教训：它在网络堆栈的不同层级上工作。

• 规则模式 (系统代理): 工作在应用层。你的浏览器知道它正在与一个代理服务器对话，并发送一个明确包含主机名（例如 claude.ai）的 HTTP CONNECT 请求。Clash 直接就拿到了主机名。

• TUN 模式 (虚拟网卡): 工作在网络层。它拦截的是原始的 IP 数据包。当一个应用程序发送数据包时，它已经通过 DNS 将 claude.ai 解析成了一个真实的 IP 地址。Clash 的 TUN 接口只能看到目标 IP，而看不到原始的主机名。

没有主机名，任何 DOMAIN-SUFFIX 规则都形同虚设。

解决方案：fake-ip 登场

这正是 Clash 的 fake-ip DNS 模式要解决的问题。启用后，Clash 会劫持所有的 DNS 请求。它不会返回真实的 IP，而是返回一个本地范围内的"假 IP"（例如 198.18.0.1/16），并在内部创建一个映射关系：假 IP <-> 真实主机名。

当 TUN 接口看到一个发往该假 IP 的数据包时，它会查询这个映射，恢复原始主机名，从而让基于域名的规则能够正确处理。

用户的配置失误

该用户启用了 fake-ip，但问题依旧。罪魁祸首隐藏在他的 DNS 设置中：他使用了 fake-ip-filter-mode: blacklist（黑名单模式）。这意味着任何匹配 fake-ip-filter 列表的域名都不会被分配假 IP。他的过滤器很可能包含了一个宽泛的规则集（如 geosite:cn），不经意间将 claude.ai 也纳入其中，导致它被解析为真实 IP，破坏了后续的规则匹配。

在调整了 DNS 过滤器后，我们取得了进展。连接日志现在可以正确显示主机名了。

问题解决了吗？还没有。流量仍然在走 DIRECT。

第二部分：意想不到的 UDP 转折​

既然主机名已经正确识别，为什么规则还是不起作用？新的截图在"类型"一栏中给出了关键线索：Tun(udp)。

根本原因：QUIC 协议 (HTTP/3)

这揭示了两种模式之间第二个，也是更微妙的区别。

• 在 规则模式 下，浏览器被强制与代理服务器建立一个基于 TCP 的 HTTP CONNECT 请求。它从不尝试使用其他协议。

• 在 TUN 模式 下，浏览器认为它正在直接与互联网对话。为了追求速度，对于任何支持最新协议的服务器（如谷歌、Cloudflare，以及此处的 Claude），它会优先尝试使用现代的 QUIC 协议（运行于 UDP 之上）。

问题至此水落石出：用户的代理服务器不支持 UDP 转发。当 Clash 试图将来自 Claude 的 UDP 数据包发送到代理服务器时，操作失败了。这条规则被跳过，流量一路向下，最终落入了配置末尾的 MATCH 规则，而该规则很可能被设置为 DIRECT。

这完美地解释了为什么规则模式能成功（因为它强制使用 TCP），而 TUN 模式会失败（因为它允许使用 UDP）。

第三部分：优雅的脚本解决方案​

最后一步是在代理节点上启用 UDP 转发。用户的 Trojan 节点配置如下：

{
    "name": "xxxx.com:443",
    "server": "xxxx.com",
    "port": 443,
    "type": "trojan",
    "password": "xxxx",
    "sni": "xxxx.com"
}

要启用 UDP，只需增加一行："udp": true。

手动修改配置文件当然可以，但如果订阅更新了怎么办？或者如果有几十个节点呢？这正是 Clash Verge 扩展脚本 发挥其真正威力的地方。

脚本不仅可以添加规则，还可以在运行时修改整个配置对象。用户意识到，他们可以通过在现有脚本中添加一个简单的循环，来一劳永逸地解决这个问题。

最终的完美脚本：

function main(config, profileName) {
    // 为所有代理节点添加或设置 'udp: true'
    if (config.proxies) config.proxies.forEach(proxy => (proxy.udp = true))

    // 保留原有的添加域名规则的逻辑
    const name = config["proxy-groups"]?.at(0)?.name

    if (name) {
        config.rules.unshift(`DOMAIN-SUFFIX,claude.ai,${name}`)
        config.rules.unshift(`DOMAIN-SUFFIX,claude.com,${name}`)
    }

    return config
}

通过这一修改，每当配置文件加载时，脚本都会自动确保每一个代理服务器都启用了 UDP 转发。这是一个健壮的、"一次设置，永久有效"的解决方案。

在应用了这个最终脚本并重启核心后，问题迎刃而解。发往 claude.ai 的 Tun(udp) 流量现在被正确地路由到了指定的代理。

关键启示​

这次排错之旅为我们掌握 Clash TUN 模式提供了几条至关重要的经验：

1. DNS 是必要条件： 要让基于域名的规则在 TUN 模式下生效，正确配置的 fake-ip DNS 是强制性的。

2. 小心过滤器： 密切关注 fake-ip-filter。一个配置错误的黑名单可能会成为你域名规则的"无声杀手"。通常，切换到 whitelist 模式更安全。

3. TUN 模式暴露协议差异： TUN 模式允许应用程序像在开放网络上一样运行，这可能意味着使用 UDP (QUIC)。请为此做好准备。

4. 为你的代理启用 UDP： 如果你使用 TUN 模式，请确保你的代理节点已设置 udp: true。否则，许多现代网络服务都会出现问题。

5. 善用扩展脚本： 不要只用脚本来添加规则。它们是动态修改整个配置的强大工具，能让你的配置免受订阅更新的影响，并省去手动编辑的麻烦。

通过理解这些层次，你就能从被 TUN 模式困扰，转变为驾驭它的全部力量，获得真正无缝和全面的路由体验。

1. 直接在外网 Windows 11 上将依赖安装好，将整个项目进行压缩，然后传输到离线服务器上，再进行解压。结果失败，因为某些包会执行 postinstall 脚本，编译一些系统相关的代码，导致失败。
2. 先试用 npm install 安装依赖，然后使用 package-lock.json 文件将整个项目的依赖树全部下载成 tgz 文件，然后在内网执行 npm install --no-registry --cache ./npm-cache --prefer-offline 安装依赖。结果失败，原因未知。
3. 在 WSL 中创建与离线服务器相同的系统环境，然后执行 npm install 安装依赖。打包再解压，依旧失败，与方法 1 相同，依旧提示缺少某些依赖。

最后一个办法是使用 verdaccio 搭建一个私有仓库。

安装 verdaccio​

这里使用 docker 安装 verdaccio，因为部署起来比较方便。

docker run -d --name verdaccio -p 4873:4873 verdaccio/verdaccio