先给一个判断框架：这个场景下省不省钱，主要由三个变量决定——每天产生几个对象、每个对象切多少片、旧对象靠谁删除，工具选 obsutil 还是 rclone 反而排在后面。两者都能做定时上传，真要二选一：只在华为云内用、操作就是把打包文件传上去，obsutil 配置更直接；还要做目录级增量同步、断点续传、以后可能换其他对象存储，就选 rclone 走 S3 兼容协议，provider 选 HuaweiOBS，endpoint 填桶所在区域的地址，并给这个账号只授予目标桶前缀的读写权限，配置文件权限设为 600。 费用按下面顺序优化： 第一，流量这一头空间不大。服务器和桶尽量建在同一区域，同区域访问 OBS 走内网解析，上传本身也不是账单大头。真正能省的是别把没变的数据反复全量传：如果数据是目录形态，用 rclone copy 做增量，未变化文件会按大小和修改时间被跳过；如果坚持每天打一个整包，那新包就是新对象，每天必然全量上传一次，这一点换什么工具都改变不了，只能靠打包前排除日志、缓存、镜像层等可再生内容，再用 zstd 压缩把包体压小。 第二，请求费主要出在分片上。分片数约等于包大小除以分片大小，默认小分片会把一个大包切成上百次 PUT。轻量服务器内存小，建议这样配，兼顾请求数和内存占用：rclone copy /data/backup/当天包.tar.zst obs:你的桶/backup/ --s3-chunk-size 64M --s3-upload-concurrency 2 --size-only --s3-no-check-bucket其中 --size-only 用大小比对代替逐个校验，避免为每个对象多发 HEAD；不要加 --checksum；用 copy 不用 sync，因为 sync 还要列举目标端做删除比对。分片也别盲目拉到几百兆，并发乘以分片大小就是内存占用，小内存机器容易先被打满。 第三，打包前先保证数据一致。SQLite 不能直接打包正在写的库文件，先执行 sqlite3 数据库路径 ".backup '快照路径'" 生成一致性快照，再把快照、Docker 卷里真正需要的数据和 compose 文件一起打包。 第四，旧包让 OBS 自己删，不要让脚本删。所有备份对象统一放在独立前缀 backup/ 下，在桶的生命周期里配两条规则：该前缀对象创建 7 天后过期删除；未完成的分段上传 3 天后自动清理，避免中断的分片长期占容量。由服务端过期删除，脚本就不用每天再发 LIST 和 DELETE 请求。存储类型保留 7 天就用标准存储，低频和归档分别有约 30 天、90 天的最短存储期，7 天就删反而会补费用。还有一点要预留：生命周期是异步执行的，实际删除可能晚几个小时到一天，存储包容量按 8 天的量估算更稳妥。 最后定时任务用 cron 加 flock 防重入，例如凌晨执行备份脚本并把日志落到本地文件；正式启用前先用 --dry-run 跑一遍，确认上传范围只有当天的包、没有误带整个数据目录。

先明确结论：你用的是传统 LXC，不是 LXD。传统 LXC 的 config 只能配网卡、地址和出网 NAT，并没有入向的端口代理功能（proxy 设备是 LXD 才有的）；所以宿主机 8080 转容器 80 这件事，只能在宿主机上做 DNAT。Debian 12 上建议直接用原生的 nftables，不要再混用 iptables 兼容层，规则写进配置文件由 systemd 加载，这也是重启不丢最稳的方式。 按你的地址假设容器固定为 10.0.3.101： 第一步，固定容器地址。DNAT 规则里写的是 IP，地址一变规则就指向空门。在容器 config 里写死 lxc.net.0.ipv4.address = 10.0.3.101/24、网关 10.0.3.1，或者在 lxc 的 dnsmasq 里按容器 MAC 做 DHCP 保留，二选一即可，改完重启容器确认地址无误。 第二步，打开转发并持久化： echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-lxc-forward.conf sysctl --system 第三步，把转发规则写成文件而不是只敲临时命令。在 /etc/nftables.conf 里保留你原有内容的基础上加入一个独立表：table ip lxc_fwd {  chain in_nat {    type nat hook prerouting priority dstnat; policy accept;    tcp dport 8080 dnat to 10.0.3.101:80  }  chain fwd {    type filter hook forward priority filter; policy accept;    ip daddr 10.0.3.101 tcp dport 80 accept    ct state established,related accept  }}注意 forward 链如果你的系统默认策略是 drop，光有 DNAT 还是过不去，所以上面把放行新连接和回包都写了。先用 nft -c -f /etc/nftables.conf 校验语法，再 systemctl enable --now nftables 并 nft -f /etc/nftables.conf 加载。这样规则来自文件，重启后 nftables 服务会自动重新加载，不依赖手工 save 快照。 第四步，云侧别漏：ECS 安全组入方向放行 TCP 8080，源地址按需要收紧到具体网段；子网若另绑了网络 ACL，也要同步放行。 验证按由内到外做，能快速定位卡在哪一层：1. 在容器里 ss -lntp 确认服务监听的是 0.0.0.0:80，只绑 127.0.0.1 时转发过去也会被拒；2. 宿主机 curl http://10.0.3.101:80，先证明网桥和服务本身通；3. 从外部机器 curl http://:8080，再看 nft list table ip lxc_fwd 里规则计数是否增长，计数为 0 说明流量没进宿主机，查安全组，计数涨但不通再查 forward 链和容器监听。另外提醒：在宿主机本机执行 curl 127.0.0.1:8080 不通不代表配置错了，本机流量不走 prerouting，需要自测就用 EIP 或另加 output 链的 dnat，不要被这一点误导。

NetworkPolicy 是一种声明式的 Pod 层白名单，由 CNI 插件翻译成底层规则执行，它本身不转发流量，只决定“谁能连谁的哪个端口”。 控制方式分三层：1. spec.podSelector 先选中被保护的 Pod，写空对象 {} 表示本命名空间全部 Pod；2. policyTypes 区分 Ingress（入站）和 Egress（出站）。某个 Pod 一旦在某个方向被策略选中，该方向就变成默认拒绝，只放行规则里明确允许的流量；完全没被策略选中的 Pod 仍然是全通的；3. ingress.from / egress.to 决定对端范围，可以用 podSelector、namespaceSelector、ipBlock 限定，再用 ports 限定协议和端口。注意：写在同一个条目里的 namespaceSelector 和 podSelector 是“且”的关系，分成两个条目则是“或”；多条策略同时命中时，允许规则是叠加的，它没有单独的拒绝规则。 一个最小例子，只允许 app=web 访问 app=api 的 8080 端口：apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata:  name: allow-web-to-api  namespace: prodspec:  podSelector:    matchLabels:      app: api  policyTypes: [Ingress]  ingress:    - from:        - podSelector:            matchLabels:              app: web      ports:        - protocol: TCP          port: 8080 使用时最容易踩的几点：一是先确认 CNI 支持，Calico、Cilium 等支持，单独的 Flannel 不实现 NetworkPolicy，策略建了也不生效还不报错；二是限制 Egress 后必须单独放行 kube-system 里 DNS 的 UDP/TCP 53，否则故障先表现为域名解析失败；三是 ports 里写的是容器端口，不是 Service 的 NodePort，跨命名空间访问要同时写对命名空间选择器；四是上线顺序建议先在测试命名空间加默认拒绝，再逐条放行，用 kubectl describe networkpolicy -n prod 核对命中范围，并用临时 Pod 做 nc/curl 的正反向验证；五是它只管 Pod 这一层，节点安全组、ELB 等外层放行还要单独检查，两层都通才算真通。

先给一个判断前提：ping 走的是 ICMP，和 SSH 走的 TCP 不是同一套规则链，两者结果不一致很正常。而且你说 SSH 能「偶发连上」，这说明 EIP、路由这条主链路大体是通的，问题更像是某一层单独拦了 ICMP，或者链路在丢包。建议按下面顺序查： 1）先在服务器上抓包分界。用控制台的远程登录（VNC）进系统执行：tcpdump -i any -nn icmp然后在本地持续 ping 公网 IP：- 完全抓不到 echo request：请求没到网卡，去查云端侧（第 2、3、5 点）；- 请求到了、服务器也发了 echo reply，但本地收不到：问题在回程，重点查子网网络 ACL 的出方向和本地网络；- 请求到了但服务器不回：问题在系统内部，看第 4 点。 2）安全组 ICMP 规则的细节。确认入方向放行的协议确实是 ICMP（或全部协议）且源地址包含你本地的公网出口 IP；还有一种常见乌龙是规则加在了出方向、或者加在了另一台实例的安全组上。安全组是有状态的，只放行入方向请求、回包会自动放行，不用单独配出方向。 3）子网网络 ACL。它和安全组最大的区别是无状态：入方向放行 ICMP 还不够，出方向也必须放行 ICMP 回包，否则现象就是请求能进、回复出不去，ping 全超时。改过子网 ACL 的环境优先查这里。 4）系统内部对 ping 的处理。两个开关最常见：- 内核参数关了回应：sysctl net.ipv4.icmp_echo_ignore_all 显示为 1 时系统对 ping 一律不回，改回 0；- 系统防火墙单独丢 ICMP：iptables -L -n | grep -i icmp 看有没有 DROP 规则，firewalld 里查 firewall-cmd --list-rich-rules，装过面板或加固脚本的机器容易中招。 5）EIP 与账号状态。EIP 带宽被设为 0、EIP 绑到了别的实例或辅助网卡、账号欠费导致 EIP 冻结，都会表现为 ping 不通。控制台逐项确认，特别是 EIP 到底绑没绑对实例。 6）源/目的检查顺带排除。ECS 网卡的这个开关开启时，实例只收发与自身 IP 严格匹配的报文；直接 ping 绑定的 EIP 一般不受它影响（EIP 是 NAT 映射），但如果这台机器还跑了 Docker 网桥、VPN 或做转发，就可能被它拦下，需要关闭。 7）别忽略本地侧和「偶发」这个线索。不少公司网络和家宽运营商会单独限制或过滤 ICMP，换手机热点 ping 一次就能验证；另外 SSH 偶发能连更像丢包而不是全断，用 mtr 公网IP 跑一分钟，看丢包从哪一跳开始，再查 EIP 带宽是否被打满（控制台 EIP 监控）、实例有没有触发安全防护的限速。 总结成一句话：先抓包分清是请求没到、回包没出、还是系统不回，再对到安全组、网络 ACL、内核/防火墙、EIP 状态这四层逐项排除，比从头逐个改配置快得多。

补一个以抓包为分界点的排查法，定位比逐项猜测快很多： 1）先确认请求包到底有没有到达服务器。在 ECS 上执行：tcpdump -i any -nn port 8080然后从本地电脑再 telnet 公网IP 8080，按结果分三种情况：- 抓不到任何 SYN 包：流量根本没到网卡，问题在云端这一侧。重点查三处：安全组规则是不是加在了这台实例实际关联的安全组上（一台 ECS 可以关联多个安全组，改错组很常见）；VPC 子网关联的「网络 ACL」有没有放行——ACL 是无状态的，出方向回包的临时端口段同样要放行；EIP 是否确实绑在这台实例上、带宽是不是 0、账号有没有欠费停机。- 能抓到 SYN、服务器也回了 SYN-ACK，但连接还是建不起来：多半是本地这一侧的问题，公司出口防火墙或运营商对 8080 这类非标端口有限制，换手机热点复测一次即可确认。- SYN 进来了但服务器不回包：问题在系统内部，看下面第 2、3 步。 2）确认服务监听地址。curl 127.0.0.1 通只能说明服务活着，不代表对外监听：ss -tlnp | grep 8080如果显示的是 127.0.0.1:8080，说明应用只绑了回环地址，外网必然不通，把应用配置改成监听 0.0.0.0 后重启。如果是 Docker 部署，再看 docker ps 的 PORTS 列：映射写成 127.0.0.1:8080->80/tcp 的同样只对本机开放，要去掉前面的 127.0.0.1；同时确认容器内应用监听的端口和映射的容器端口一致。 3）系统自带防火墙。安全组之外系统里还有一层，装过宝塔、1Panel 这类面板时尤其容易被改动：- firewalld 体系：firewall-cmd --list-ports，没有 8080 就执行 firewall-cmd --add-port=8080/tcp --permanent && firewall-cmd --reload- Ubuntu：ufw status 显示 active 的话执行 ufw allow 8080/tcp也可以直接 iptables -L -n --line-numbers 看 INPUT 链前面有没有 DROP/REJECT 规则挡路。 结合你的现象（本机 curl 通、外网 telnet 超时），最常见的就是应用只监听回环地址、或者 Docker 端口映射绑了 127.0.0.1，先跑一遍 ss -tlnp，多半就能定位。

先一句话区分：蓝绿部署是“整体切换”，两套环境整备、流量一次性从蓝切到绿；金丝雀发布是“按比例放量”，新版本先接 1%~5% 流量，看指标再逐步放大。选型的关键其实是看这次变更的失败代价、你能承受多大的爆炸半径：选蓝绿的场景：1. 版本之间有不可兼容的变更（数据库 schema、协议、外部依赖），只能整套换。2. 需要秒级回滚——蓝绿回滚就是把流量再切回蓝环境，基本秒级；金丝雀回滚要把流量比例调回，路径更长。3. 团队还没有成熟的指标灰度体系，或者发布窗口明确、变更后要集中验证。代价：资源要准备双份；切换瞬间所有流量都压到新版本，一旦有问题影响面是 100%，所以切换前必须在绿环境做完整的验证。选金丝雀的场景：1. 流量足够大（不然 1% 就是几十个请求，错误率变化没有统计意义，区分不出是运气不好还是新版本真有问题）。2. 有完善的可观测性：错误率、P99 延迟、业务指标都看得到。3. 变更风险集中在性能或个别场景，想用真实流量暴露问题、把影响面控制在小范围内。代价：需要流量切分能力（Service Mesh、Ingress 权重、网关灰度），需要自动化决策（人工盯盘容易看漏）。一个落地的判断清单：1. 能不能同时跑两个版本？不能 → 蓝绿；能 → 看下面。2. 有没有足够流量和指标？没有 → 蓝绿 + 人工验证；有 → 金丝雀。3. 出问题能容忍多大影响面？极小 → 金丝雀；宁愿赌一把全量 → 蓝绿。两个容易忽略的前置条件：1. 回滚预案要包括数据回滚。新版本写了新字段，回滚后旧版本可能读不了，只准备流量回滚不够。2. 灰度期间配置、缓存 key、消息队列消费者也要一起灰度。只灰度 Web 层、后台任务全量跑新逻辑，等于没灰度。实践里两者经常组合用：日常迭代走金丝雀（5% 观察 30 分钟，指标正常逐步到 100%）；重大变更（比如换存储引擎、协议升级）走完整蓝绿。金丝雀发现异常就停掉放量，蓝绿在切换前做最后一轮全量验证，分工不同，互不替代。

一句话概括：长轮询是“用 HTTP 假装实时”，WebSocket 是“真正的双向长连接”。工作方式对比长轮询：客户端发 HTTP 请求，服务端有数据才返回，没有就 hold 住直到超时；客户端收到响应立刻再发下一个请求。每条消息都对应一次完整的 HTTP 事务（请求头+响应头加起来动辄几百字节）。WebSocket：客户端发一次带 Upgrade: websocket 的 HTTP 请求，服务端返回 101 Switching Protocols 之后，这条 TCP 连接就变成双向帧通道，双方随时可以推帧，帧头只有 2~14 字节，延迟基本就是一次网络 RTT。怎么选？看谁发起、频率多高1. 只需服务端单向推送、频率低（分钟级）：长轮询或 SSE。SSE（HTTP 流式推送）能自动重连、复用 HTTP 鉴权，性价比最高。2. 双向高频实时（IM、协同编辑、行情推送、游戏、在线客服）：WebSocket。WebSocket 的运维成本比长轮询“重”，上线前要处理好这几件：1. 网关/负载均衡必须显式支持协议升级和长连接。Nginx 至少配这三行：proxy_set_header Upgrade $http_upgrade;proxy_set_header Connection "upgrade";proxy_read_timeout 3600s;2. 长连接长期占用服务端资源：注意文件描述符上限、每个连接的内存占用；多实例部署时，连接落到 A 实例、消息从 B 实例发，需要广播机制或一致性哈希做连接亲和。3. 必须做心跳（ping/pong）+ 断线重连（指数退避加随机抖动）。长轮询反而因为“每次都是新请求”天然带重试语义。4. 用 wss 必须配证书；鉴权要在握手时完成，因为连接建立后没有逐请求的 token 校验了，握手时校验一次、之后靠连接维持身份。结论：只是要“服务端能推消息”，两者都能用；但要的是“低延迟双向实时通信”，就用 WebSocket，别让长轮询去硬扛高频场景。

平衡成本与性能的核心是“先度量、再选型、小步验证、定期复核”，而不是一上来就定死规格。分享一个可操作的流程：一、先测出真实负载，别凭感觉拍规格上线前用压测工具把业务的真实水位打出来：wrk -t4 -c200 -d60s http://your-server/拿到 QPS、P95 延迟、CPU/内存/带宽的实际水位，再去选规格。没有压测数据的选型都是拍脑袋。二、按瓶颈类型选规格族，而不是堆 vCPUCPU 密集（转码、科学计算）：计算型规格，CPU:内存 1:2 起步就够。内存密集（Redis、ES、JVM 应用）：内存优化型，1:8 甚至更高；JVM 堆只给到内存的 60-70%，留足堆外内存和系统内存。磁盘密集（数据库、日志写入）：瓶颈往往在磁盘，先升级云硬盘类型（超高 IO）而不是加 CPU，盲目加 CPU 对 IO 瓶颈毫无帮助。网络密集（网关、代理）：注意规格的 PPS 和带宽上限，小规格的网络收发包能力限制很死。三、成本侧的杠杆基线容量用包年包月（通常比按需便宜 40% 以上），波动部分用按需；可中断的离线任务（CI 构建、批处理）用竞价实例，价格低很多但会被回收，不要放有状态服务。横向扩展优先于纵向升配：两台小规格通常比一台大规格更便宜、更可靠，前提是应用无状态、会话可外置。别忘了磁盘和带宽：很多人只算实例费用，其实磁盘占账单的比例常被低估，按实际 IOPS 需求选盘，不要默认全上超高 IO。四、上线后用数据复核跑一两周后看监控：CPU 长期低于 20% 就降一档，长期高于 70% 或高峰打满就升配或横向扩。Linux 里看真实内存要用 free 的 available 列，buff/cache 会让“已用”虚高：free -hiostat -x 1关注 P95/P99 和峰值，别只看平均值——平均 30% 的 CPU 可能每天高峰都在打满。一句话总结：没有“性价比最高”的规格，只有最贴合你负载曲线的规格。用数据驱动选型，性能和成本自然就平衡了。

换个角度，补充一条新手可以直接照抄的落地路线，核心是先小后大、按量起步、定期复盘：1. 起步别贪大：学习阶段直接选通用型 2 核 4G 按需计费起步，系统盘 40G 高效云盘就够。先把业务跑起来，出现性能瓶颈时再针对性升级，比一上来买 8 核 16G 长期闲置划算得多。2. 用监控代替拍脑袋：云监控 CES 里给 CPU、内存利用率各配一条告警，比如连续几天峰值低于 20% 就降配，持续高于 70% 就升配。每两周花 10 分钟看一次数据，决定升还是降。3. 付费方式跟着稳定度走：规格还没定型前一律按需；连续跑满一个月且规格不再变的，转包年包月，一般能省三到四成；测试环境、定时任务这类用完就关机或直接释放，不要 24 小时空转。4. 别为附属资源多花钱：带宽按实际出网峰值选，学习机 1 到 2M 起步；系统之间调用走 VPC 内网不花钱；快照和多余的弹性 IP 定期清理，这些小钱加起来也不少。一句话：学习期按需小规格起步，稳定后转包年包月，让监控数据替你做升降配决策。

这类症状（外面能 ping 通服务器，服务器里面 ping 不通任何地址、打不开网页、RDP 也连不上）基本可以锁定是出方向网络不通，再加上远程桌面的入口没放行。按下面顺序排查：一、先解决服务器上不去网1. 确认有没有公网出口：控制台 ECS 详情，看是否绑定了弹性公网 IP。如果只有内网 IP，服务器本身就没有公网出路，打不开百度是正常的，需要绑定 EIP 或经 NAT 网关 SNAT 上网。2. 检查安全组出方向规则：ECS 关联的安全组，出方向要有放行 0.0.0.0/0（或至少 80、443、53 端口）的规则。很多人只配了入方向，漏了出方向。3. 检查子网路由表：VPC 路由表里，默认路由 0.0.0.0/0 的下一跳应指向 Internet 网关或 NAT 网关，自定义路由表漏配默认路由是常见坑。4. 区分 DNS 还是网络问题：在服务器上执行 nslookup www.baidu.com，如果域名解析失败但 ping 8.8.8.8 能通，就是 DNS 问题，把网卡 DNS 改成 114.114.114.114 或 223.5.5.5 再试。5. Windows 上用 Test-NetConnection www.baidu.com -Port 443 测端口连通性，比只 ping 更能说明问题。二、再解决 RDP 连不上1. 安全组入方向放行 TCP 3389，先临时把来源设为 0.0.0.0/0 验证，通了之后再收紧为自己的公网 IP。2. 服务器上确认已启用远程桌面：此电脑右键属性，远程设置里允许远程连接，并确认 Remote Desktop Services 服务正在运行。3. 兜底手段：用控制台的 VNC 远程登录进去排查，VNC 不依赖网络配置，进去之后再逐项改。建议顺序：VNC 登录、ipconfig 看地址、查 EIP 绑定和安全组出入方向，先恢复出网，再修 RDP。这样一套下来基本能定位到问题。