王叔走都是上坡 · 独立开发者

移动宽带 SSH 不到海外 VPS？CF + nginx 反向代理的全套方案

panic3170@gmail.com (王叔走都是上坡) — Tue, 16 Jun 2026 00:00:00 GMT

移动宽带 SSH 不到海外 VPS？CF + nginx 反向代理的全套方案

核心结论：国内网络移动运营商会主动阻断到海外 VPS 的 SSH 流量。正确做法是让所有流量走 Cloudflare CDN，国内网络看不到真实 VPS IP，配合 nginx 网站防主动探测。本文提供从零到一的完整部署方案。

3 分钟摘要：

移动宽带到 VPS 的 SSH 流量被 GFW 识别并阻断
用 Cloudflare CDN 隐藏真实 VPS IP（免费方案）
xray VLESS + WebSocket 加密代理流量
nginx 网站防御 G网主动探测

实测环境：RackNerd VPS（Ubuntu 22.04）+ 3X-UI + Clash Verge + 域名走 Cloudflare 适用场景：家庭移动宽带（移动/电信/联通）被国内网络移动运营商阻断 SSH 直连海外 VPS 最终效果：根本不用 SSH 直连 VPS，所有代理流量都套上 Cloudflare CDN + 网站防主动探测

一、问题背景

从 RackNerd 买了一台美国 VPS，IP 104.223.xxx.xxx，给了 root 账号密码让我从 22 端口登录。

异常表现：

ping 这个 IP ✅ 通
家里中国移动宽带 ssh root@IP -p 22 ❌ 卡住
改成 ssh -p 443 也卡住
手机 4G/5G 热点 ssh root@IP -p 22 ✅ 正常
服务器侧 sshd 日志显示 fatal: Timeout before authentication for <我的国内IP>

结论：家里移动宽带到 VPS 的 SSH 流量被 GFW/移动运营商识别并阻断。不是 VPS 的问题，是 ISP/GFW 的事。

客服让"换 ISP 试试"——这等于踢皮球，正确做法是让所有流量走 Cloudflare CDN，GFW 看不到真实 VPS IP。

二、最终架构

┌────────────────────────────────────────┐
│  客户端（家里移动宽带）                  │
│   Clash Verge → 节点 rackvps-cf         │
└─────────────┬──────────────────────────┘
              │  TLS 443（看起来是普通 HTTPS）
              ▼
┌────────────────────────────────────────┐
│  Cloudflare Edge（全球 CDN 节点）       │
│   - 隐藏真实 VPS IP                     │
│   - 缓解 GFW 主动探测                   │
└─────────────┬──────────────────────────┘
              │  TLS 443（CF 回源）
              ▼
┌────────────────────────────────────────┐
│  VPS nginx (0.0.0.0:443)               │
│   路径 /ws  → 127.0.0.1:10000 → xray  │
│   其他路径  → /var/www/fake (假博客)    │
└─────────────┬──────────────────────────┘
              │
              ▼
┌────────────────────────────────────────┐
│  xray (VLESS + WebSocket)              │
│   鉴权通过 → 流量转发到互联网            │
└────────────────────────────────────────┘

三层防护：

CF CDN — 客户端只看到 CF 节点，看不到 VPS IP
nginx fallback — GFW 主动探测看到的是普通博客
xray VLESS+WS — 真实代理流量加密传输

三、前置准备

项目	说明
域名	自己的域名（已在 Cloudflare 接入，能改 NS）
VPS	任意海外 VPS（本文用 RackNerd Ubuntu 22.04）
3X-UI	VPS 上已装好（如果没装，参考 3X-UI 安装）
客户端	Clash Verge（Windows / macOS / iOS / Android 都有）

本文用到的占位符（实际配置时替换成自己的）：

占位符	含义	示例
`<域名>`	CF 上接入的域名	`qzz.io`
`proxy.<域名>`	代理用的子域	`proxy.qzz.io`
	VPS 真实 IP	`104.223.xxx.xxx`
	3X-UI 生成的客户端 UUID	`b1a4d8e7-xxxx-...`

四、VPS 端配置

4.1 安装 3X-UI（如果还没装）

SSH 到 VPS（用手机 4G 热点连），执行：

bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh)

安装过程中会问：

用户名：自己设（默认 admin）
密码：自己设（默认 admin，务必改）
面板端口：自己设（默认 54321，建议改成 2053 之类不常见的）

安装完后访问 http://:<面板端口>，能看到登录页就 OK。

4.2 创建入站（VLESS + WebSocket + TLS）

3X-UI 面板 → Inbounds → + Add Inbound：

字段	填什么
Remark	`cf-vless`（随便起）
Protocol	`vless`
Listen IP	留空（默认 0.0.0.0，先这样，最后再改）
Port	`443`
Transmission	`ws`
Path	`/ws`
Security	`TLS`
Certificate	暂时留空（下一步填）
Key	暂时留空
ALPN	`h2, http/1.1`

Clients → 点 + Add Client：

Email：随便填
点 🔄 生成 UUID → 复制这个 UUID 备用（客户端要填）

点 Create 保存。

4.3 生成 Cloudflare Origin Certificate

CF 控制台 → SSL/TLS → Origin Server → Create Certificate：

Hostname：填 proxy.<域名>（比如 proxy.qzz.io）
Validity：15 years
点 Create

复制生成的两段内容：

Certificate 框内容（含 -----BEGIN CERTIFICATE-----）→ 存到 VPS /etc/ssl/cf/cert.pem
Private key 框内容（含 -----BEGIN PRIVATE KEY-----）→ 存到 VPS /etc/ssl/cf/key.pem

在 VPS 上执行：

mkdir -p /etc/ssl/cf
nano /etc/ssl/cf/cert.pem    # 粘贴证书内容，Ctrl+O 保存，Ctrl+X 退出
nano /etc/ssl/cf/key.pem     # 粘贴私钥内容
chmod 644 /etc/ssl/cf/cert.pem
chmod 600 /etc/ssl/cf/key.pem

回到 3X-UI 面板，把入站重新编辑：

Certificate 字段：粘贴 cert.pem 全部内容
Key 字段：粘贴 key.pem 全部内容
保存

4.4 配置 Cloudflare 加密模式和 WebSocket

CF 控制台：

SSL/TLS → Overview：

加密模式选 完整 (严格)（不要选"灵活"，否则 CF 到源站不加密，xray 收不到 TLS 握手）

Network：

WebSockets → On

4.5 在 Cloudflare 添加 DNS 记录

CF 控制台 → DNS → Records → + Add record：

字段	值
Type	`A`
Name	`proxy`（子域名前缀，最终域名是 `proxy.<域名>`）
IPv4 address
Proxy status	`Proxied`（橙色云朵） ← 必须选这个
TTL	`Auto`

保存后验证（Windows PowerShell）：

nslookup proxy.<域名>

期望返回 CF 的 IP（104.21.x.x / 172.67.x.x 等），不是 VPS IP。如果返回 VPS IP，说明橙色云朵没开。

4.6 验证：客户端能通过域名连代理

到此步 VPS 还在用 3X-UI 单独跑（监听 443 + TLS）。先在客户端验证代理能不能用。

Clash Verge 临时配置：

proxies:
  - name: "rackvps-cf"
    type: vless
    server: proxy.<域名>
    port: 443
    uuid: 
    network: ws
    ws-opts:
      path: /ws
      headers:
        Host: proxy.<域名>
    tls: true
    servername: proxy.<域名>
    alpn:
      - h2
      - http/1.1

proxy-groups:
  - name: "PROXY"
    type: select
    proxies:
      - rackvps-cf
      - DIRECT

rules:
  - MATCH,PROXY

Clash Verge → Profiles → 粘贴上面 YAML → 启用 → 系统代理打开 → 浏览器开 Google 验证。

通了之后继续下面步骤，加 nginx 反代做防探测。

4.7 安装 nginx

VPS 上：

apt update && apt install -y nginx

⚠️ 注意是 apt install 不是 install（常见笔误）。

4.8 写假网站内容

mkdir -p /var/www/fake
cat > /var/www/fake/index.html <<'EOF'



    
    My Notes
    


    My Notes
    
        Hello, world
        2026-01-15
        Just a personal blog. Nothing to see here.
    
    
        About
        This is my personal site. Drop me a line if you want to chat.
    


EOF

cat > /var/www/fake/robots.txt <<'EOF'
User-agent: *
Disallow: /admin/
Disallow: /private/
Allow: /
EOF

4.9 写 nginx 配置

cat > /etc/nginx/conf.d/proxy.conf <<'EOF'
# 默认 server：处理无 SNI / 主动探测请求（防御 GFW）
server {
    listen 443 ssl http2 default_server;
    server_name _;

    ssl_certificate     /etc/ssl/cf/cert.pem;
    ssl_certificate_key /etc/ssl/cf/key.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;

    root  /var/www/fake;
    index index.html;

    location / {
        try_files $uri $uri/ /index.html;
    }
}

# 真实代理：匹配 proxy.<域名>
server {
    listen 443 ssl http2;
    server_name proxy.<域名>;

    ssl_certificate     /etc/ssl/cf/cert.pem;
    ssl_certificate_key /etc/ssl/cf/key.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;

    root  /var/www/fake;
    index index.html;

    # WebSocket 路径 → xray
    location /ws {
        proxy_pass http://127.0.0.1:10000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_read_timeout 3600s;
    }

    # 默认：返回假网站
    location / {
        try_files $uri $uri/ /index.html;
    }
}

# HTTP → HTTPS 重定向
server {
    listen 80;
    server_name proxy.<域名>;
    return 301 https://$host$request_uri;
}

# 80 端口 default_server（防止端口扫描暴露）
server {
    listen 80 default_server;
    server_name _;
    root /var/www/fake;
    index index.html;
    location / {
        try_files $uri $uri/ /index.html;
    }
}
EOF

# 删掉 nginx 默认站（避免冲突）
rm -f /etc/nginx/sites-enabled/default

# 检查 + 启动
nginx -t
systemctl enable --now nginx

4.10 修改 3X-UI 入站（让出 443 端口给 nginx）

3X-UI 面板 → Inbounds → 编辑 cf-vless 入站：

字段	改为什么
Port	`443` → `10000`
Listen IP	留空 → `127.0.0.1`
Security	`TLS` → `None`（关掉，TLS 由 nginx 处理）
数字证书	清空

保存。

4.11 重启服务（顺序很重要）

x-ui restart           # 3X-UI 重启，xray 切到 127.0.0.1:10000
systemctl restart nginx # nginx 现在能抢到 443 了

⚠️ 顺序必须是先 x-ui restart 再 systemctl restart nginx。否则 xray 还占着 443，nginx 启动会报 bind() failed (98: Address already in use)。

4.12 验证

# 1. 端口监听
ss -tlnp | grep -E ':80|:443|:10000'
# 期望：
#   nginx 在 *:80、*:443
#   xray 在 127.0.0.1:10000（必须是 127.0.0.1，不是 0.0.0.0）

# 2. 域名访问假网站
curl -sI https://proxy.<域名>/
# 期望：HTTP/2 200

# 3. 看假网站内容
curl -s https://proxy.<域名>/ | grep "My Notes"
# 期望：能找到 My Notes 字样

五、客户端配置（Clash Verge）

5.1 创建 Profile

Clash Verge → Profiles → New Profile → 选空白模板。

5.2 写入配置

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies:
  - name: "rackvps-cf"
    type: vless
    server: proxy.<域名>
    port: 443
    uuid: 
    network: ws
    ws-opts:
      path: /ws
      headers:
        Host: proxy.<域名>
    tls: true
    servername: proxy.<域名>
    alpn:
      - h2
      - http/1.1
    skip-cert-verify: false
    udp: true

proxy-groups:
  - name: "PROXY"
    type: select
    proxies:
      - rackvps-cf
      - DIRECT

rules:
  - GEOIP,LAN,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

把 <域名> 和替换成自己的。

5.3 启用代理

顶部 Proxies → PROXY 组 → 选 rackvps-cf
主界面打开 System Proxy 或 TUN Mode（TUN 更彻底）

5.4 验证代理生效

浏览器访问：

https://ip.sb — 应显示美国 IP 104.223.xxx.xxx
https://www.google.com — 应能打开
https://ipinfo.io/json — 应显示 country: "US"

或 PowerShell：

curl.exe -s https://ifconfig.me
# 期望：104.223.xxx.xxx

六、故障排查

6.1 浏览器报 `HTTP 521`

CF 连不上 VPS。在 VPS 上：

ss -tlnp | grep 443

看不到任何 443 监听 → nginx 没起来 → systemctl restart nginx
看到 xray 在 443 → 3X-UI 入站没改 10000/127.0.0.1/None → 改完 x-ui restart 再 systemctl restart nginx

6.2 浏览器报 `HTTP 502`

nginx 起来了但连不上 xray：

ss -tlnp | grep 10000

看不到 127.0.0.1:10000 → xray 没在 10000 监听 → 3X-UI 入站改没改好。

6.3 Clash Verge 节点显示 Timeout

按顺序检查：

域名解析：
```
nslookup proxy.<域名>
```
必须是 CF IP，不能是 VPS IP。
CF SSL 模式：必须是 完整 (严格)，不能是 灵活。
CF WebSockets：必须是 On。
UUID 是否对：3X-UI 面板复制 UUID 重新填。
路径是否对：客户端 /ws 和 3X-UI Path: /ws 必须完全一致。

6.4 nginx 启动报 `bind() to 0.0.0.0:443 failed (98: Unknown error)`

443 端口被占。先确认 xray 没在 443：

ss -tlnp | grep 443

看到 xray → 3X-UI 入站改成 10000/127.0.0.1/None → x-ui restart → 再启 nginx。

6.5 假网站能访问但 `/ws` 报 400

nginx 转发到 xray 的配置出问题：

路径 /ws 必须跟 3X-UI 入站 Path: /ws 完全一致
nginx 配置里 Connection "upgrade" 引号必须是英文双引号
nginx 转发 HTTP/1.1 给 xray，xray 必须也是 WS 模式（不能是别的传输）

6.6 Windows PowerShell `curl` 用不了

PowerShell 的 curl 是 Invoke-WebRequest 的别名，参数不一样。用真 curl：

curl.exe -sI https://proxy.<域名>/
curl.exe -s https://proxy.<域名>/ | findstr "My Notes"

或装 Git for Windows 自带 curl.exe。

6.7 改了 3X-UI 入站后代理掉了

3X-UI 入站千万别改回 443/0.0.0.0/TLS——nginx 就会因为端口冲突起不来。

合法改动：端口改 10001/10002...、路径改 /ws2 /ws3...，Listen IP 永远 127.0.0.1，Security 永远 None。

七、日常维护

7.1 看代理流量

VPS 上：

tail -f /var/log/nginx/access.log | grep /ws

持续输出 GET /ws HTTP/1.1 101 ... 的日志。101 = WebSocket 升级成功 = 代理流量。

7.2 改假网站

nano /var/www/fake/index.html
systemctl reload nginx

7.3 加新节点

3X-UI 创建新入站：端口 10001，Listen 127.0.0.1，Security None，Path /ws2

nginx 加新转发：

location /ws2 {
    proxy_pass http://127.0.0.1:10001;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_read_timeout 3600s;
}

systemctl reload nginx
客户端加节点，path 填 /ws2

7.4 重启服务

systemctl restart nginx
x-ui restart

7.5 防火墙

UFW 通常 inactive 即可，需要开：

ufw allow 443/tcp
ufw allow <3X-UI面板端口>/tcp    # 比如 2053

八、关键点回顾

关键点	错误做法	正确做法
CF DNS 记录	灰色云朵（DNS only）	橙色云朵（Proxied）
CF SSL 模式	灵活	完整 (严格)
3X-UI 入站端口	443	10000 + Listen 127.0.0.1 + Security None
CF Origin Cert	用 Let's Encrypt	用 CF Origin Cert（15 年）
nginx 启动顺序	先启 nginx 再改 3X-UI	先 `x-ui restart`，再 `systemctl restart nginx`
nginx fallback 路径	留空 Path	Path `/` + Dest `127.0.0.1:8080` （用方案 A 时）
Windows curl	`curl -sI URL`	`curl.exe -sI URL`（带 .exe 后缀）

九、最终目录结构

VPS 文件结构：
/etc/ssl/cf/
├── cert.pem              # CF Origin 证书
└── key.pem               # CF Origin 私钥
/var/www/fake/
├── index.html            # 假博客首页
└── robots.txt            # 防爬虫提示
/etc/nginx/conf.d/
└── proxy.conf            # nginx 反代配置
/usr/local/x-ui/          # 3X-UI 安装目录
└── bin/config.json       # 3X-UI 生成的 xray 配置

十、写在最后

整套方案的核心思路：

不要直连 VPS IP（被 GFW/ISP 干扰）
所有流量套上 Cloudflare CDN（GFW 不敢全面封 CF）
VPS 上不要让 xray 直接接 TLS（主动探测会暴露 xray）
用 nginx 终结 TLS + 转发 WS（探测时看到的是普通博客）
3X-UI 监听 127.0.0.1 的非标准端口（永远不暴露到公网）

这样就实现了：

国内移动宽带可以科学上网 ✅
国外网络也照样能用 ✅
GFW 主动探测看到的是博客 ✅
VPS IP 永远不会直接暴露 ✅
日常维护只需要改 3X-UI 入站和 nginx 配置 ✅

常见问题 FAQ

为什么 SSH 连不上 VPS，但 ping 是通的？

这是 GFW/移动运营商对 SSH 流量的主动识别与阻断。GFW 维护了常用协议的特征库，SSH（22/443 端口）的握手包有明显特征。一旦匹配，直接 RST 断开连接。ping 用的是 ICMP 协议，不在阻断范围内，所以会通。

解决方法：不要直连 VPS IP，让所有流量走 Cloudflare CDN，GFW 看不到真实 IP。

Cloudflare 免费版够用吗？

够用。本方案用的就是 CF 免费版：

DNS 解析：免费
CDN 加速：免费
Origin Certificate：免费 15 年有效期
不限流量（公平使用）

唯一限制：免费版不支持 Spectrum（TCP/UDP 转发），但 VLESS + WebSocket 走 HTTPS 443 端口完全够用。

一定要用 RackNerd VPS 吗？其他 VPS 行不行？

可以。本方案对 VPS 厂商没有要求，只要满足：

系统：Ubuntu 20.04+ / Debian 11+ / CentOS 7+
能 SSH 登录（用手机 4G 热点或机场中转）
IP 没被墙（可以用 ping.chinaz.com 测一下）

推荐 VPS 厂商（按性价比）：RackNerd、CloudCone、BandwagonHost（搬瓦工）、HostDare、Vultr（按小时计费）。

为什么用 VLESS 而不是 VMess 或 Trojan？

协议	特点	推荐度
VLESS	新一代轻量协议，无加密依赖 TLS	⭐⭐⭐⭐⭐（推荐）
VMess	老牌协议，自带加密但效率低	⭐⭐⭐
Trojan	伪装成 HTTPS，但握手特征明显	⭐⭐
Shadowsocks	已被 GFW 部分识别	⭐⭐

VLESS + WebSocket + TLS 是目前最难被 GFW 识别的组合，因为流量完全包裹在标准 HTTPS 中。

nginx 假网站有什么作用？

防 GFW 主动探测。GFW 会对 Cloudflare CDN 后面的 IP 发起 HTTPS 探测请求：

如果 443 端口返回的是 xray 的特征 → 标记为代理，封 IP
如果 443 端口返回的是普通博客 → 当作正常网站放行

nginx 假网站就是让"非代理用户"访问时看到的是博客，真实代理用户访问 /ws 路径才走 xray。

3X-UI 面板要不要暴露到公网？

绝对不要。3X-UI 面板必须：

监听 127.0.0.1（仅本机访问）
端口改非标准（如 2053、31456）
设置强密码 + 改默认用户名 admin

访问面板通过 SSH 端口转发：ssh -L 2053:127.0.0.1:2053 root@VPS_IP，然后浏览器开 http://127.0.0.1:2053。

这套方案会被封吗？

大概率不会长期稳定，但能用很久。G网不断升级，本质是一场猫鼠游戏。本方案的优势：

VPS IP 永远不暴露 → 封 IP 难度极大
网站防探测 → G网看不到 xray 特征
Cloudflare CDN 缓冲 → 真实流量被分散到 CF 全球节点

降低风险的额外建议：

不要在 VPS 上做违规内容
节点不要分享给太多人
定期更换 UUID 和路径

一个域名能部署多个节点吗？

可以。在 Cloudflare DNS 里加多个 A 记录（如 proxy1、proxy2、proxy3），都指向同一 VPS IP。客户端可以配置多个节点做负载均衡 / 故障转移。

本文只做技术方案，不涉及任何法律问题。请在法律范围内使用。

完。

86 手机号无法登录 Telegram 终极解决方案：绕过付费验证码 + 旧设备验证找回账号

panic3170@gmail.com (王叔走都是上坡) — Sun, 14 Jun 2026 00:00:00 GMT

86 手机号无法登录 Telegram 终极解决方案：绕过付费验证码 + 旧设备验证找回账号

核心结论：86 手机号登录 Telegram 提示"收费验证码"或把验证码发到旧设备，本质是 Telegram 的反垃圾 + 多设备验证机制在生效。前提条件是：你必须还拥有这个 86 号码、绑定的邮箱、且开启了二次验证（2FA）并记得密码。满足这三者，可以用第三方客户端 Telega 走"邮箱 + 2FA 密码"通道直接登录，绕开短信付费和旧设备验证。本文提供亲测可行的完整操作步骤。

3 分钟摘要：

86 号码 + 邮箱 + 二次验证密码 = 找回账号的三要素，缺一不可
用第三方客户端 Telega（绕过 Google Play 校验版本）登录，触发邮箱 + 2FA 通道
登录成功后再用官方 Telegram 登录、更新到最新版本
整个过程不需要原手机短信、不需要旧设备在线

事故背景：旧手机上登录的 Telegram 因手机摔坏无法开机，新设备登录时 Telegram 提示需要发送付费验证码，或把验证码发到旧设备上，折腾半个多月最终找回。本文记录真实操作流程和踩过的坑。

一、事故还原：为什么 86 手机号登录 Telegram 会失败

1.1 触发场景

最常见的两种卡死情况：

情况	现象	原因
A. 收费验证码	提示"This phone number can only be used to send a paid SMS"	Telegram 检测到号码被滥用过，强制走付费通道
B. 发到旧设备	提示"Code sent to your other device"	旧设备还在线（即使关屏），Telegram 优先推送到已登录设备
C. 登录即掉线	旧设备上提示"New login attempt"，新设备看不到验证码	所有会话验证码都推到旧设备，新设备收不到

1.2 底层原因

Telegram 的登录策略按以下顺序判断：

是否在 30 天内登录过该设备 → 是，直接放行
是否绑定了其他已登录设备 → 是，推送验证码到其他设备
是否开通了二次验证 → 是，验证密码
手机号是否被标记 → 是，强制付费短信
以上都不通过 → 免费短信

对于 86 号码（+86），第 4 条命中率很高，因为大量黑产用虚拟号段注册过。Telega 客户端可以绕过这一层判断，直接走二次验证通道。

1.3 为什么旧设备掉线就无法登录

Telegram 8.0 之后引入了"设备群组"概念：

账号登录的所有设备构成一个群组
新设备登录时，验证码优先推送到群组中"最活跃"的设备
旧手机即使关屏，只要 Telegram 在后台运行，就会被识别为活跃设备
旧手机掉线后，新设备才有机会收到短信

但 86 号码可能等不到这一步——Telegram 在新设备请求时直接拒绝免费通道。

二、前置条件（缺一不可）

在开始之前，请先确认以下三件事，缺一找回失败：

必备项	用途	怎么确认
① 86 手机号	Telegram 账号的注册号	必须是当前可用的、能接打电话的卡
② 绑定邮箱	接收登录验证码	在 Telegram → Settings → Edit Profile 里看，没有就补一个
③ 二次验证密码	登录时的第二道验证	在 Settings → Privacy and Security → Two-Step Verification 设置过

特别强调：

如果没开二次验证 → 无法绕过，只能等 Telegram 客服（回复极慢）
如果忘了二次验证密码 → 先用邮箱重置（在登录页点"Forgot password?"）
如果邮箱没绑定 → 登录时无法走邮箱通道，这个方法无效

三、完整操作步骤（亲测有效）

第一步：下载 Telega（绕过 Google Play 验证的版本）

⚠️ 这一步骤卡了最久。很多人卡在"Telega 安装不上 / 打开就闪退 / 提示需要从 Google Play 验证"。90% 的问题是版本不对。

1.1 为什么必须用特定版本

Telega 是一款第三方 Telegram 客户端（基于 TDLib 二次开发），有两个特殊能力：

跳过 Google Play 完整性校验（CH Play Integrity）
直接暴露 2FA + 邮箱登录通道

但官方版本会触发校验，需要找已经破解校验的 APK（通常 7.x 或 8.x 的某个特定构建）。

1.2 安装步骤

准备一台手机或安卓模拟器（推荐夜神、雷电、MuMu 等主流模拟器）
卸载手机上所有旧版 Telega / Telegram（避免数据冲突）
获取可用的 Telega APK（建议找博主或社区获取，版本很关键，网传的"最新版"基本都用不了）
安装时如果提示"未知来源"，到设置里允许安装
安装完成后不要打开，先断网（飞行模式）再打开，避免它自动更新到坏版本

重要提示：Telega 的"可用版本号"会随 Telegram 官方更新而变化。我测试时可用的是 x.x.x 版本（文末可以找我要当前可用版本）。不要去 Telegram 群组随便下载——大部分是引流号或带木马的。

第二步：用 Telega 登录（走邮箱 + 2FA 通道）

打开 Telega
输入你的 86 手机号（格式 +86 138xxxxxxxx，前面带 +86）
选 Log in by email（如果有这个选项）
- 如果没看到这个选项 → 版本不对，换一个版本
去邮箱收验证码（5 分钟内有效）
输入邮箱验证码
提示输入二次验证密码（Two-Step Verification Password）→ 输入你设置的密码
看到 "Loading chats..." → 登录成功

💡 整个过程完全不需要手机短信，完全不需要旧设备。如果到这里你已经看到自己的聊天记录，恭喜，账号找回了。

第三步：回到官方 Telegram 登录

Telega 是第三方客户端，不适合长期使用（数据同步可能有延迟、二次验证可能重复弹）。找回账号后，按下面的步骤切回官方客户端：

在手机上下载官方 Telegram（Google Play 或 App Store）
用同一个 86 手机号登录
这次因为你已经成功通过二次验证，Telegram 不会再发付费验证码——它会直接发送免费短信到你的手机
输入短信验证码
提示输入二次验证密码 → 输入
登录成功

🎉 到此为止，账号已经完全找回了。 接下来在 Settings → Devices 里终止所有其他设备的会话（包括 Telega 那个），防止再出问题。

第四步：更新 Telegram 到最新版

登录后系统会提示更新 → 立即更新
更新完成后重启
检查二次验证是否还在 → Settings → Privacy and Security → Two-Step Verification
强烈建议把二次验证密码记到密码管理器（1Password / Bitwarden），下次再遇到设备丢失能直接找回

四、踩过的坑（避坑指南）

4.1 版本问题（最常见）

症状：

Telega 安装后打开就闪退
打开后停在加载页面不动
提示"需要从 Google Play 更新"
提示"应用未经认证"

原因：Google Play Integrity（以前叫 SafetyNet）会检测 APK 是否"官方来源"。第三方修改版会触发检测。

解决：

✅ 用已经 Magisk 隐藏 + 校验通过的版本
✅ 模拟器用户必须用带 root 的镜像（夜神安卓 9+ 自带 root）
❌ 不要用最新版（基本都坏了）
❌ 不要在应用商店下载（都是引流版）

4.2 邮箱收不到验证码

症状：Telega 提示"Verification code sent to your email"，但邮箱里找不到。

排查：

检查垃圾邮件箱
检查"促销"标签（Gmail 会自动归类）
等待 2-3 分钟（Telegram 邮箱通道有延迟）
重新点击"Resend code"
如果超过 10 分钟还没收到 → 邮箱没绑对这个账号，用这个 Telega 客户端是没用的

4.3 二次验证密码忘了

症状：Telega 登录时输入密码提示"Invalid password"。

解决：

回到 Telega 登录页
点 "Forgot password?"
走邮箱重置流程（这又需要邮箱能收到邮件）
重置后重新登录

4.4 86 号码本身不可用

症状：你的 86 卡已经注销 / 长期欠费停机。

解决：

Telegram 不会因为你换号就锁账号——只要邮箱 + 2FA 密码还在，直接用 Telega 登录
登录后到 Settings → Edit Profile → Phone Number → Change Number，换成新号（这一步可选）

4.5 登录后聊天记录是空的

症状：登录成功但看不到以前的聊天记录。

原因：Telega 是新客户端，不会自动同步云端历史。

解决：

退出 Telega
用官方 Telegram 登录
官方客户端会从 Telegram 云端拉取全部历史记录（这个过程需要科学上网）

五、找回后的安全加固

账号找回只是开始，强烈建议做以下防护，避免下次再翻车：

5.1 完善账号信息

设置项	路径	建议
邮箱	Settings → Edit Profile → Email	必须绑定可用邮箱
二次验证	Settings → Privacy and Security → Two-Step Verification	必须开启，强密码
备用邮箱	Settings → Privacy and Security → Two-Step Verification → Set Email	设置"重置密码用邮箱"
登录邮箱	同上	开启"允许通过邮箱登录"

5.2 清理活跃会话

Settings → Devices → Terminate All Other Devices
留下当前设备，其他全部踢出
包括 Telega 那个会话——它不加密云端同步

5.3 备份二次验证密码

不要只记在脑子里
用 1Password / Bitwarden / Apple 钥匙串管理
同时手写一份在物理笔记本（极端情况，账号比设备值钱）

5.4 解除 +86 限制（可选）

如果你能搞到非 +86 的海外号码（Google Voice / TextNow 等），可以把 Telegram 主号换成海外号。86 号码触发付费验证码的概率显著高于其他号段。

六、关键点回顾

关键点	错误做法	正确做法
客户端选择	用官方 Telegram 死磕	用第三方 Telega（特定版本）
登录方式	等手机短信	走邮箱 + 2FA 通道
前置条件	假设只要手机号	手机号 + 邮箱 + 2FA 密码三件套
找回后	继续用 Telega	切回官方 Telegram，更新到最新版
二次验证	不开 / 忘记密码	必须开 + 密码管理器保存
APK 来源	群组里随便下	找博主/可信社区获取验证过可用版本

七、写在最后

这套方案本质上利用了 Telegram 客户端协议的冗余登录通道——同一个账号支持手机号、邮箱、二维码、2FA 密码等多种方式登录。当主通道（手机短信）被封死时，备用通道（邮箱 + 2FA）依然可以工作。前提是你在账号"健康"的时候就把这些通道都打开。

如果你现在还没遇到这个问题，强烈建议立即做两件事：

检查 Telegram 的二次验证是否开启
检查邮箱是否绑定且可用

等到手机真的摔坏、号码真的停机再做就来不及了。

常见问题 FAQ

为什么 86 号码登录 Telegram 提示要付费验证码？

Telegram 出于反垃圾和反黑产考虑，对被滥用过的号段（包括部分 +86 虚拟号段、二手回收号段）强制走付费短信验证。这不是你的账号问题，是号段问题。普通 86 手机号触发概率较低，但确实存在。解决方法是用 Telega 走邮箱 + 2FA 通道绕开。

没有二次验证密码可以用这个方法吗？

不能。二次验证密码是这套方法的核心——它替代了"手机短信"这个被卡住的验证环节。如果你没开二次验证，只能走 Telegram 官方支持（回复极慢，通常 1-3 个月），或者用付费短信（不划算且有时也收不到）。

邮箱没绑定怎么找回？

几乎无法找回。Telegram 在注册时强烈建议绑定邮箱，但很多人没做。这种情况下的选项：

提交 Telegram 账号支持表单，说明情况，等回复
找一台曾经登录过这个账号的设备（旧手机、平板、桌面端），重新激活后导出聊天记录
放弃账号，重新注册（聊天记录会全部丢失）

强烈建议现在就去 Telegram 设置里检查邮箱是否绑定。

Telega 安全吗？会不会泄露聊天记录？

Telega 是开源的第三方 Telegram 客户端（基于 TDLib），不经过任何中转服务器——它直接连接 Telegram 官方 API。聊天记录加密方式和官方客户端一样。但因为是非官方客户端：

✅ Telegram 协议层面安全
⚠️ 应用本身的安全性取决于具体版本
⚠️ 不要用网上随意下载的版本——找可信来源

找回账号后立即切回官方客户端是更稳妥的做法。

找回账号后还需要做什么？

按本文第五章的清单做完整的安全加固：完善邮箱、开启二次验证、清理活跃会话、备份密码。这是避免下次再翻车的关键。

这个方法对非 86 号码有效吗？

有效。这个方法的本质是用备用登录通道（邮箱 + 2FA）替代主通道（手机短信），对所有号段都适用。+86 号码触发付费验证码的问题更严重，所以这套方法在 86 用户中需求最高。

Telega 客户端在哪里下载？

不建议在公开渠道随意下载。网传的"最新版"90% 都触发了 Google Play 校验检测，安装后用不了。建议找已经验证过可用版本号的博主或社区获取。本文作者也提供当前可用版本（找我要 APK），留言或私信即可。

登录后看到"This account is banned"怎么办？

这是账号被封禁，和登录通道无关。Telegram 封禁通常基于手机号，而不是设备。解决方法：

提交申诉：https://telegram.org/support
等官方回复（可能几小时到几周）
如果申诉无果，只能换号重新注册（聊天记录会丢失）

从零到一：我的独立开发之路

panic3170@gmail.com (王叔走都是上坡) — Fri, 15 May 2026 00:00:00 GMT

从零到一：我的独立开发之路

为什么选择独立开发

2023年初，我做出了一个重要决定：离开稳定的工作，成为一名独立开发者。这个决定并非一时冲动，而是经过深思熟虑的结果。

在大公司工作的几年里，我积累了丰富的技术经验，参与了多个大型项目的开发。但随着时间推移，我越来越渴望更大的创作自由，想要打造真正属于自己的产品。

第一个产品的诞生

独立后的前三个月，我专注于开发第一款产品 TaskFlow。这是一个任务管理应用，灵感来源于我自己的需求。在开发过程中，我学到了很多：

技术选型

选择了 React Native，因为需要同时支持 iOS 和 Android
使用 Firebase 作为后端，快速实现功能
采用 TypeScript，提高代码质量

产品设计

最初的版本很简单，只有基础的任务管理功能。但我注重细节，确保每个交互都流畅自然。这种对用户体验的执着，后来成为产品的核心竞争力。

第一批用户

产品上线后，我通过 Product Hunt、Twitter 和技术社区进行推广。最初的用户增长很慢，第一周只有不到100个下载。

但我没有气馁，而是积极收集用户反馈，快速迭代。每当收到用户的建议，我都会认真考虑，尽快实现合理的需求。

突破与成长

三个月后，TaskFlow 的用户数突破了 1000。这个里程碑对我意义重大，证明了产品的价值。

随后的发展更加顺利：

6个月：5000 用户
1年：10000+ 用户
开始有稳定的收入来源

经验总结

这一年的独立开发经历让我收获颇丰：

产品思维：从用户需求出发，而不是技术驱动
快速迭代：先发布最小可行产品，再逐步完善
持续学习：独立开发者需要掌握全栈技能
营销推广：好产品也需要好的推广策略
心态调整：接受失败，从错误中学习

未来展望

未来，我计划继续深耕独立开发领域，推出更多有价值的产品。同时，我也希望通过写作和分享，帮助更多想要转型的开发者。

如果你也有独立开发的想法，欢迎与我交流！

Vue 3 Composition API 完全指南

panic3170@gmail.com (王叔走都是上坡) — Tue, 28 Apr 2026 00:00:00 GMT

Vue 3 Composition API 完全指南

什么是 Composition API

Composition API 是 Vue 3 引入的一组基于函数的 API，它允许我们使用函数来组织组件逻辑，而不是选项对象。

为什么需要 Composition API

解决选项式 API 的痛点

逻辑复用困难：在选项式 API 中，逻辑分散在不同的选项中
类型推断不足：TypeScript 支持不够完善
代码组织受限：相关逻辑必须分散在不同部分

核心概念

ref 和 reactive

ref 用于创建响应式的基本类型数据：

import { ref } from 'vue'

const count = ref(0)
console.log(count.value) // 0
count.value++
console.log(count.value) // 1

reactive 用于创建响应式的对象：

import { reactive } from 'vue'

const state = reactive({
  count: 0,
  name: 'Vue'
})

computed

计算属性是基于它们的响应式依赖进行缓存的：

import { ref, computed } from 'vue'

const firstName = ref('John')
const lastName = ref('Doe')

const fullName = computed(() => {
  return `${firstName.value} ${lastName.value}`
})

watch 和 watchEffect

watch 用于观察特定的响应式数据源：

import { ref, watch } from 'vue'

const count = ref(0)
watch(count, (newVal, oldVal) => {
  console.log(`count changed from ${oldVal} to ${newVal}`)
})

watchEffect 会自动追踪依赖：

import { ref, watchEffect } from 'vue'

const count = ref(0)
watchEffect(() => {
  console.log(`count is ${count.value}`)
})

最佳实践

逻辑复用

使用组合式函数来复用逻辑：

// useCounter.ts
import { ref } from 'vue'

export function useCounter(initialValue = 0) {
  const count = ref(initialValue)
  
  const increment = () => count.value++
  const decrement = () => count.value--
  const reset = () => count.value = initialValue
  
  return {
    count,
    increment,
    decrement,
    reset
  }
}

代码组织

按功能组织代码，而不是按选项类型：

// 搜索相关逻辑
const searchQuery = ref('')
const searchResults = ref([])

// 分页相关逻辑
const currentPage = ref(1)
const pageSize = ref(10)

总结

Composition API 为 Vue 带来了更灵活的代码组织方式和更好的类型支持。掌握它可以让你写出更优雅、更可维护的 Vue 代码。

React Native 性能优化实战

panic3170@gmail.com (王叔走都是上坡) — Wed, 15 Apr 2026 00:00:00 GMT

React Native 性能优化实战

性能问题的常见表现

在开发 React Native 应用时，我们经常会遇到以下性能问题：

界面卡顿：列表滚动不流畅
启动时间长：应用打开需要等待
内存泄漏：应用运行一段时间后崩溃
帧率下降：动画不流畅

列表优化

使用 FlatList 而非 ScrollView

FlatList 是高性能的列表组件，它会按需渲染可见的项：

 }
  keyExtractor={item => item.id}
/>

优化 renderItem

确保 renderItem 返回的组件是纯组件：

const ListItem = React.memo(({ item }) => {
  return 
    {item.title}
  
})

图片优化

使用合适的图片格式

对于图标，使用 SVG
对于照片，使用 WebP 格式
压缩图片大小

使用 FastImage

FastImage 是一个高性能的图片加载库：

import FastImage from 'react-native-fast-image'

内存管理

清理定时器和监听器

在组件卸载时清理：

useEffect(() => {
  const timer = setInterval(() => {
    // do something
  }, 1000)
  
  return () => clearInterval(timer)
}, [])

避免内存泄漏

确保正确处理异步操作：

useEffect(() => {
  let isMounted = true
  
  fetchData().then(data => {
    if (isMounted) {
      setData(data)
    }
  })
  
  return () => {
    isMounted = false
  }
}, [])

总结

性能优化是一个持续的过程，需要不断地监测和改进。通过以上方法，可以显著提升 React Native 应用的性能。

期货交易的七条铁律：从亏损到稳定盈利的思考

panic3170@gmail.com (王叔走都是上坡) — Fri, 20 Mar 2026 00:00:00 GMT

期货交易的七条铁律：从亏损到稳定盈利的思考

做期货这几年，踩过的坑、爆过的仓、熬过的夜，最终都沉淀成这七条心得。期货交易本质上不是预测行情，而是管理自己。以下每一条都是真金白银换来的，建议反复读、慢慢悟。

一、大部分时间都是在等待信号

交易最反直觉的一件事：80% 的时间，你应该什么都不做。

市场每天都有波动，但真正值得出手的信号屈指可数。很多人亏损的根本原因不是技术不行，而是手痒——看到一根阳线就追，看到一个消息就冲，结果频繁交易、手续费亏一大堆、胜率被拉得很低。

实战做法

提前写好交易计划：什么形态进场、什么情况止损、目标位在哪
没有信号就空仓：哪怕空仓一周、一个月，也比乱开仓强
每天复盘 1 小时，盯盘 10 分钟：大部分盯盘时间都是在和自己的情绪作斗争

市场永远不缺机会，缺的是耐心和纪律。

二、一定不要抗单，及时止损

这是期货交易的第一铁律，没有之一。

抗单的本质是什么？是拒绝承认错误，是用"希望"代替"事实"。当行情反向运行时，你心里清楚这笔单子错了，但就是不愿意平仓——"再等等，可能会反弹"、"已经亏这么多了，砍了太可惜"。

结果呢？小亏拖成大亏，大亏拖到爆仓。

止损的核心原则

原则	含义
进场前定好止损位	不到位置不进场，到了位置坚决砍
止损幅度 ≤ 单笔可承受亏损的 1-2%	比如 10 万本金，单笔最多亏 1000-2000 元
止损后不立刻反手	错了就错了，市场不缺下一次机会
不接受"等等看"	一旦到止损位，机械执行，不留任何商量余地

止损是把小错变成可控成本，不止损是把小错变成致命伤。

三、顺应趋势

趋势是你的朋友，永远不要和趋势作对。

这句话听起来像废话，但真正做起来极难。逆势交易有几个典型表现：

下跌趋势中抄底"摸顶"
在均线下方反复做多
"我觉得已经跌得够多了，该反弹了"

事实是：你觉得，和市场觉得，是两回事。

顺势的几个判断方法

看大周期定方向：日线级别是上涨，就只做多；是下跌，就只做空（或观望）
均线系统：价格在 20 日均线上方，视为多头趋势；下方视为空头趋势
高低点抬升 / 下降：上涨趋势的回调低点一个比一个高；下跌趋势的反抽高点一个比一个低
不预测顶底：趋势没破就持有，破位就离场

趋势什么时候结束？等市场告诉你，不要替市场决定。

四、如果有盈利，调整为移动止损

这是让利润奔跑的关键技巧。

很多新手的问题是：盈利了拿不住，亏损了死扛——典型的"赚小亏大"，长期下来必亏。

移动止损的做法

进场后，先设好初始止损位（保护本金）。当行情朝着有利方向运行超过一定幅度后，把止损位移动到成本价（保本），然后随着行情继续推进，不断把止损位向上/向下移动。

举个例子（做多）：

入场价 100，止损 95（亏 5 个点）
涨到 110，止损移到 100（保本）
涨到 120，止损移到 110（锁定 10 个点盈利）
涨到 130，止损移到 120（锁定 20 个点盈利）
直到被打掉出场

这样最坏的结果是小赚，好的结果是大赚。

移动止损的本质是：让市场决定你赚多少，而不是你主观猜顶。

五、如果跟上趋势，要有拿得住的勇气

这一条和上一条是配套的。会止损是入门，能拿住单子才是进阶。

很多人在趋势初期赚了点钱，结果一个回调就被吓出来，然后眼睁睁看着行情继续走几百点——"我曾经拥有过，最后却没能拿住"。

拿不住单子的根本原因

仓位太重：一个正常回调就让你心理崩溃
盯盘太紧：每一秒的波动都在冲击你的情绪
没有移动止损：每次回调都担心利润回吐
缺乏对趋势的信仰：不相信自己的判断

解决方法

降低仓位：永远只拿让你"睡得着觉"的仓位
少看盘：每天只看 2-3 次收盘价，不要看实时波动
日线定方向，小时线找入场：大周期坚定持有
想清楚最坏情况：进场前就想清楚"如果错了亏多少"，想清楚了就不怕

趋势的利润是坐出来的，不是做出来的。

六、多分析基本面和技术面结合，一定要深入一个品种的全链路

很多交易者亏钱，是因为只看一个面：

只看技术面：被假突破、消息面打脸
只看基本面：忽略入场点位，扛单扛到爆仓

真正能稳定盈利的人，都是基本面 + 技术面双修。

基本面要研究什么

维度	关键问题
供需关系	产量、库存、消费、出口数据
季节性规律	农产品有明显的种植/收获周期
政策面	限产、补贴、关税、环保政策
宏观环境	美元指数、利率、汇率、大宗商品周期
产业链利润	上游成本、下游需求、产业链各环节的博弈

为什么要"深入一个品种"？

期货品种太多了，螺纹钢、豆粕、原油、黄金、白银……每个品种都有完全不同的"性格"。

新手最常见的错误：今天做这个，明天做那个，每个品种都只懂皮毛
正确做法：选定 1-2 个你最熟悉、最有资源的品种，深入研究 2-3 年

研究透了什么：

这个品种的旺季淡季是什么时候
历史上大的行情是怎么启动的
主要的矛盾点（供需缺口、库存周期）通常出现在什么时间窗口
主力资金的习惯（产业资金、套保盘、投机资金的博弈）

广撒网不如深挖井。精通一个品种，远胜于浅尝十个品种。

七、调整好心态

最后一条，也是最难的一条。

技术可以学，方法可以练，但心态只能悟。期货交易到最后，拼的不是谁技术好，而是谁的情绪更稳定。

心态崩盘的典型场景

连续亏损后：急于翻本，重仓出击 → 爆仓
连续盈利后：过度自信，放大杠杆 → 吐回去
重仓被套后：睡不着、吃不下、影响工作生活 → 心态彻底崩溃
错过行情后：FOMO（害怕错过）情绪主导，乱开仓 → 亏损

调整心态的实战方法

把交易当成一份普通工作：每天按时看盘、复盘、休息，不要把它当成赌博
设置单日/单周亏损上限：到了就停手，关掉软件出去走走
保持交易之外的生活：运动、读书、社交，别让交易成为你生活的全部
接受"不完美"：不可能每笔都对，稳定盈利的关键是"赚的时候多赚，亏的时候少亏"
写下交易日记：每笔单子进场前想什么、进场后情绪如何、最后为什么出场——长期复盘会让你看清自己
相信时间复利：10 万做到 100 万不是一年完成的，是 3-5 年稳定小赚积累的

市场专治各种不服。真正的高手，都是"心很平"的人。

写在最后

期货交易是一场和自己的人性弱点的战斗。

贪婪 → 让你重仓、让你不止盈
恐惧 → 让你拿不住单子、让你在底部割肉
急躁 → 让你频繁交易、让你追涨杀跌
侥幸 → 让你不止损、让你和"应该"做对的事对着干

这七条心得，每一条都对应一种人性弱点。当你真的能做到"大部分时间等待、严格止损、顺势而为、移动止损、拿得住单子、深耕一个品种、心态平和"，你就会发现——

稳定盈利不是奇迹，是纪律的副产品。

常见问题 FAQ

新手应该用多少仓位？

1-2% 原则：单笔交易的最大亏损，不超过账户总资金的 1-2%。

举例：10 万账户，单笔最多亏 1000-2000 元。如果止损位 1000 元，仓位就开 1-2 手（合约价值 / 止损幅度 = 仓位）。

新手建议：从 0.5 手、甚至 0.1 手开始，用最少的钱买经验。等连续 3 个月稳定盈利了，再逐步加仓。

止损设多少个点合适？

没有标准答案，取决于：

品种波动率：螺纹钢、原油波动大，止损要宽；豆粕、白银波动小，止损可以窄
持仓周期：日内短线 5-15 个点；波段 30-100 个点；趋势跟踪 100-500 个点
账户资金：单笔亏损 ≤ 1-2% 倒推止损幅度

实战建议：

进场前用 ATR（平均真实波幅） 指标衡量近期波动
止损位 = 入场价 ± (1.5 × ATR)
这样能过滤掉大部分正常波动，又能在趋势反转时及时出场

一天交易几次合适？

高手一天可能只交易 0-1 次。

频繁交易是亏损的根源之一。每次交易都有手续费、滑点、情绪消耗。即使胜率 50%，频繁交易的手续费也会吃掉所有利润。

判断标准：

一周交易 3-5 次：合理
一天交易 5+ 次：过度交易
一天交易 10+ 次：必亏

改掉频繁交易的技巧：

设单日最大亏损额度（亏 1000 元就关软件）
没信号就关掉行情软件
把"交易次数"列入复盘指标

趋势跟踪的胜率是不是很低？

是的，通常 30-40%。

趋势跟踪的核心是"截断亏损，让利润奔跑"：

胜率低（30-40%）但盈亏比高（平均盈利 / 平均亏损 ≥ 2:1）
10 笔单子：3 笔赚 20%，7 笔亏 5%
最终收益：3×20% - 7×5% = 60% - 35% = +25%

为什么这种策略能稳定盈利？

抓到大趋势一次，盈利能覆盖多次小亏损
心理负担小，规则明确，可复制
不需要"高胜率"也能赚钱

怎么判断趋势结束了？

三个核心信号：

关键位突破失败：上涨趋势中，价格多次上攻前高失败 → 趋势可能反转
均线拐头：5 日均线、20 日均线死叉，且价格跌破 20 日均线
结构破坏：上涨趋势的回调低点一个比一个高，突然出现"低点下移" → 趋势结束

不要猜顶底：用规则替代主观判断，让市场告诉你答案。

如何调整交易心态？

6 个实战方法：

每天运动 30 分钟：交易是脑力劳动，身体是本钱
冥想 / 呼吸练习：连续亏损时，闭眼深呼吸 5 分钟
设置"禁交易"日：每周至少 1 天完全不看盘
写交易日记：每笔单子记录"为什么进场"、"出场时情绪如何"
找交易伙伴：互相监督，分享心得（但不要过度讨论行情）
接受"亏损是成本"：没有 100% 胜率的策略，亏损是交学费

心态崩盘的信号：连续 3 笔亏损后加大仓位、报复性交易、失眠、影响工作生活。出现这些信号必须强制休息。

资金管理有多重要？

资金管理 > 入场点位 > 选品种。

很多新手花 80% 精力研究入场信号，但真正的胜负在资金管理：

同样 50% 胜率的策略：
- 好的资金管理 → 稳定盈利
- 差的资金管理 → 必爆仓

核心规则：

单笔亏损 ≤ 1-2%
同时持仓不超过 3 个品种
总仓位不超过 50%（永远不要满仓）
连续亏损 3 笔后减半仓位

完。

Git 工作流最佳实践

panic3170@gmail.com (王叔走都是上坡) — Tue, 10 Mar 2026 00:00:00 GMT

Git 工作流最佳实践

分支策略

Git Flow

这是一个经典的分支模型：

main：主分支，存放稳定代码
develop：开发分支，集成所有功能
feature/*：功能分支，开发新功能
release/*：发布分支，准备发布
hotfix/*：紧急修复分支

Trunk Based Development

适合持续集成的简单模型：

main：唯一的长期分支
功能通过短生命周期的特性分支开发

提交规范

使用约定式提交

格式：():

常见类型：

feat：新功能
fix：修复 bug
docs：文档更新
style：代码格式
refactor：重构
test：测试
chore：构建/工具更新

示例：feat(auth): add login with Google

保持提交粒度适中

每个提交应该是一个独立的逻辑单元
避免超大提交
避免过于琐碎的提交

代码审查

PR 审查流程

创建 PR 时提供清晰的描述
添加相关的测试
至少需要一个 reviewer 批准
使用 CI/CD 自动检查

审查要点

代码正确性
代码质量
性能考虑
安全性
可维护性

总结

选择适合团队的工作流，并坚持执行，可以显著提高团队的协作效率。

TypeScript 实用技巧

panic3170@gmail.com (王叔走都是上坡) — Wed, 25 Feb 2026 00:00:00 GMT

TypeScript 实用技巧

类型推断

类型守卫

使用类型守卫来缩小类型范围：

function isString(value: unknown): value is string {
  return typeof value === 'string'
}

类型断言

使用 as 进行类型断言：

const element = document.getElementById('my-element') as HTMLElement

高级类型

泛型

创建可重用的泛型函数：

function identity(arg: T): T {
  return arg
}

条件类型

根据条件选择类型：

type IsString = T extends string ? true : false

映射类型

基于现有类型创建新类型：

type Readonly = {
  readonly [P in keyof T]: T[P]
}

工具类型

Partial

使所有属性变为可选：

type Partial = {
  [P in keyof T]?: T[P]
}

Pick

选择指定的属性：

type Pick = {
  [P in K]: T[P]
}

Omit

排除指定的属性：

type Omit = Pick>

总结

掌握这些 TypeScript 技巧可以让你写出更类型安全、更优雅的代码。

王叔走都是上坡 · 独立开发者

移动宽带 SSH 不到海外 VPS？CF + nginx 反向代理的全套方案

移动宽带 SSH 不到海外 VPS？CF + nginx 反向代理的全套方案

一、问题背景

二、最终架构

三、前置准备

四、VPS 端配置

4.1 安装 3X-UI（如果还没装）

4.2 创建入站（VLESS + WebSocket + TLS）

4.3 生成 Cloudflare Origin Certificate

4.4 配置 Cloudflare 加密模式和 WebSocket

4.5 在 Cloudflare 添加 DNS 记录

4.6 验证：客户端能通过域名连代理

4.7 安装 nginx

4.8 写假网站内容

My Notes

Hello, world

About

4.9 写 nginx 配置

4.10 修改 3X-UI 入站（让出 443 端口给 nginx）

4.11 重启服务（顺序很重要）

4.12 验证

五、客户端配置（Clash Verge）

5.1 创建 Profile

5.2 写入配置

5.3 启用代理

5.4 验证代理生效

六、故障排查

6.1 浏览器报 HTTP 521

6.2 浏览器报 HTTP 502

6.3 Clash Verge 节点显示 Timeout

6.4 nginx 启动报 bind() to 0.0.0.0:443 failed (98: Unknown error)

6.5 假网站能访问但 /ws 报 400

6.6 Windows PowerShell curl 用不了

6.7 改了 3X-UI 入站后代理掉了

七、日常维护

7.1 看代理流量

7.2 改假网站

7.3 加新节点

7.4 重启服务

7.5 防火墙

八、关键点回顾

九、最终目录结构

十、写在最后

常见问题 FAQ

为什么 SSH 连不上 VPS，但 ping 是通的？

Cloudflare 免费版够用吗？

一定要用 RackNerd VPS 吗？其他 VPS 行不行？

为什么用 VLESS 而不是 VMess 或 Trojan？

nginx 假网站有什么作用？

3X-UI 面板要不要暴露到公网？

这套方案会被封吗？

一个域名能部署多个节点吗？

86 手机号无法登录 Telegram 终极解决方案：绕过付费验证码 + 旧设备验证找回账号

86 手机号无法登录 Telegram 终极解决方案：绕过付费验证码 + 旧设备验证找回账号

一、事故还原：为什么 86 手机号登录 Telegram 会失败

1.1 触发场景

1.2 底层原因

1.3 为什么旧设备掉线就无法登录

二、前置条件（缺一不可）

三、完整操作步骤（亲测有效）

第一步：下载 Telega（绕过 Google Play 验证的版本）

1.1 为什么必须用特定版本

1.2 安装步骤

第二步：用 Telega 登录（走邮箱 + 2FA 通道）

第三步：回到官方 Telegram 登录

第四步：更新 Telegram 到最新版

四、踩过的坑（避坑指南）

4.1 版本问题（最常见）

4.2 邮箱收不到验证码

4.3 二次验证密码忘了

4.4 86 号码本身不可用

4.5 登录后聊天记录是空的

五、找回后的安全加固

5.1 完善账号信息

5.2 清理活跃会话

5.3 备份二次验证密码

5.4 解除 +86 限制（可选）

六、关键点回顾

七、写在最后

6.1 浏览器报 `HTTP 521`

6.2 浏览器报 `HTTP 502`

6.4 nginx 启动报 `bind() to 0.0.0.0:443 failed (98: Unknown error)`

6.5 假网站能访问但 `/ws` 报 400

6.6 Windows PowerShell `curl` 用不了