先说结论：新手用 OBS 最容易踩的坑集中在三处：权限、对象模型、存储类型与计费。按下面顺序逐个排除，大多数问题不用提工单就能定位。 一、定位步骤：先分清是 403、404 还是下载不了 1. 用浏览器或 curl 直接打开对象链接，看返回码：403 是权限问题；404 是对象名、路径或区域错了；能打开但下载乱码或很慢，是存储类型或网络问题。2. 在 OBS 控制台确认三点：桶在哪个区域、桶的存储类别、对象确实存在且 key 没抄错。一个字母大小写、一个多余的斜杠，都会 404。3. 再看是谁在访问：控制台登录的账号、AK/SK 的 IAM 用户、还是匿名用户，不同身份走的权限完全不一样。 二、具体操作：权限先这样查 桶默认是私有的，对象上传后别人打不开是正常现象，不是上传失败。不要图省事把整个桶改成公共读，正确做法是保持桶私有，只给需要的人授权： - 控制台路径：对象存储 OBS > 桶列表 > 目标桶 > 权限 > 桶策略 / IAM 授权，确认访问者有没有该桶的读取权限，IAM 用户要同时看桶策略和 IAM 策略，两处都允许才放行。- 临时给外部人员下载：用控制台生成临时 URL，或用链接分享并设置有效期，过期自动失效，不要长期公开。- 本地排查对象是否存在：obsutil ls obs://桶名>/obsutil ls obs://桶名>/对象前缀>/如果 ls 能看到对象，说明对象在，只是权限或链接不对；如果 ls 也看不到，先核对桶名、区域和 key。 三、对象模型：OBS 没有真正的文件夹 OBS 是扁平的对象存储，控制台里的“文件夹”只是 key 里带斜杠的显示效果。常见坑有两个：一是以为删了“文件夹”就删了里面的对象，实际要逐个删对象；二是上传同名对象会直接覆盖旧对象，没有回收站概念，覆盖前先确认。 四、存储类型与计费：归档对象不能直接下载 标准、低频访问、归档、深度归档的价格和取回方式不一样。归档对象要先在控制台做恢复，等恢复完成才能下载，直接下载会报错。生命周期规则也要小心：配错了前缀或时间，旧对象会被自动转存或过期删除。先在控制台确认对象的存储类别和生命周期规则，再处理下载问题。 五、验证：改完做这三件事 1. 用 curl -I 对象链接> 看返回码从 403 变成 200，再下载一次确认内容完整。2. 换一个匿名浏览器窗口打开链接，确认没有因为登录状态“看起来能打开”而误判。3. 大文件上传后用 obsutil ls 看对象大小和上传时间，确认没有只传了一半的分段碎片。 六、注意事项 不要把整个桶设为公共读，不要把 AK/SK 写进前端代码或公开仓库；删除桶之前先清空对象和未完成的分段上传，否则删不掉；桶名全局唯一，跨区域访问要确认桶所在的区域，不要用错区域的域名。

结论：新手用 OBS 最容易踩的坑不是配置多，而是默认就是私有、权限分三层、临时链接会过期、生命周期删了不能直接恢复。先按桶策略、对象权限、防盗链这个顺序查一遍，基本能避开九成的 403 和费用问题。定位步骤：第一步，先确认对象到底能不能公开访问。新建桶默认是私有，对象默认不公开，直接在浏览器打开对象链接会返回 403，这是正常的，不是桶坏了。第二步，用 curl -I 看响应头，区分是 403（无权限）、404（对象不存在或拼错了 Key）、还是 200 但下载的是旧版本（CDN 没刷新）。第三步，对照时间点：是刚建桶就访问不了，还是以前能访问、现在突然不能，刚好对上改过桶策略、防盗链或者生命周期的时间。具体操作：想让一个对象能被人直接下载，先在 OBS 控制台确认对象本身的权限，再决定是只给单个对象设为公共读，还是给整个桶配桶策略。不要为了图省事就把整个桶设为公共读，正确的做法是：公开的静态资源单独放一个桶，非公开的文件放另一个桶。批量检查权限和对象是否存在，可以在 Linux 上用 obsutil：obsutil ls obs://my-bucketobsutil stat obs://my-bucket/index.htmlcurl -I https://my-bucket.obs.cn-north-4.myhuaweicloud.com/index.html如果是给别人临时下载，不要把对象设为公共读，用临时授权 URL，生成时设置好过期时间，过期后链接自动失效；如果是做成网页引用，注意把静态网站托管和备份分开处理。跨域请求 403，先去桶的 CORS 规则里把来源域名、方法和请求头加全，改完用浏览器重新发一次请求验证。验证：改完权限后做三件事。第一，退出账号后用无痕浏览器打开对象链接，确认能下载。第二，换一个不在白名单里的来源域名再访问一次，确认防盗链确实拦得住。第三，让需要的人用临时链接重新下载一次，确认过期时间正确、没有提前失效。注意事项：一、不要把 AK、SK 写进前端代码或者公开的配置文件里，泄露后别人能直接操作你的桶。二、生命周期规则启用前先检查范围，把重要数据排除在外，版本控制开启后再删文件，还能通过历史版本恢复一次。三、冷、归档一类低频存储的对象直接访问会额外收费，取回需要先恢复到标准存储再下载。四、不建议在还在开发验证的桶上绑定 CDN加速，CDN 缓存过期前会看到旧内容。五、定期去访问日志和费用账单里看有没有异常的访问量和外网流出流量。

结论：先按业务类型定规格族，再按峰值负载定核数和内存，留 20%~30% 余量；先用按量计费的小规格压测验证，达标后再买包年包月，不要一步到位买大规格。一、定位步骤：先量化，再选型1. 先量化负载：并发用户数、峰值 QPS、单请求 CPU 耗时、内存占用、磁盘 IOPS 和带宽。没有数字就选型，等于盲选。2. 按业务分族：普通 Web 应用、后端接口选通用型；CPU 密集（计算、编码、渲染）选计算型；缓存、数据库、大内存应用选内存型；AI 推理、图形处理选 GPU 型。3. 按峰值定大小：以峰值时刻的资源占用为准，不是按平均值。二、具体操作：给一套可直接用的起步配置1. 轻量应用（个人博客、测试环境、小工具站）：2 核 4GB 起步，系统盘选极速型 SSD，带宽按实际峰值选。2. 常规业务（企业官网、内部系统、中小电商后端）：4 核 8GB 起步，通用型。3. 计算密集（批量计算、视频转码、科学计算）：8 核 16GB 起步，计算型。4. 内存密集（Redis、MySQL、大 JVM 应用）：按内存比 1:8 配，例如 4 核 32GB，内存型。5. 在控制台创建时先选按量计费，跑 1~2 天真实流量后再决定是否转包年包月；同一业务不要把数据库和应用混装在一台机器上。三、验证：用三条命令看是否选小了或选大了```uptimefree -htop -b -n 1 | head -20```压测或峰值时段观察：CPU 持续高于 70%、内存使用率持续高于 80%、负载 load 持续高于核数，就要升配；反之 CPU 长期低于 20%、内存长期低于 30%，说明规格买大了，可以降配。配合云监控看 7 天曲线，不要只看一瞬间的峰值。四、注意事项1. 不要只比单价：要比“满足同样性能的总成本”，规格、带宽、云硬盘要一起算，带宽和磁盘选错也会拖慢业务。2. 变更规格前先做备份或创建快照，业务低峰期操作，变更后重新跑一遍上面的验证命令。3. 数据库、大内存应用对磁盘 IOPS 敏感，系统盘和数据盘不要都用普通盘。4. 业务量会涨就留扩容余量，但也不要一次买 2 倍规格，云上随时可以升配，先压测、再定型、最后包年，才是最省钱的顺序。

结论：SWR 的权限要分两层做。IAM 层决定这个账号能不能进 SWR、能做什么操作；SWR 组织层决定这个账号在某个组织里只能拉取，还是可以推送。想让开发人员只能拉取、不能推送，就不要给 SWR 管理员或完全访问，只给只读权限，推送用单独的流水线账号。这样即使开发人员拿到镜像地址，也推不上去、删不掉。定位步骤：先分清问题出在哪一层，再动手改。1. 先确认这个人的身份：是主账号，还是 IAM 用户；他属于哪个用户组，现在被授予了哪些 SWR 相关策略。2. 再确认他要访问的镜像在哪个组织、哪个仓库，这个组织和仓库是不是私有的。3. 按“先 IAM、后组织”的顺序查：IAM 上给了完全访问，就算组织里只给只读也可能漏；只看组织权限、不看 IAM 授权，同样查不全。具体操作：1. 在 IAM 新建一个用户组，例如 swr-developers，附加系统策略 SWR ReadOnlyAccess，只做查看和拉取，不要附加 SWR Administrator 或完全访问类策略。把开发人员加入这个组，不要给个人直接授权，方便以后统一收回。2. 在 SWR 控制台进入组织管理，选择对应的组织，在权限管理里把开发人员或该用户组加进来，只给拉取用的只读角色，不要给能推送、删除仓库的角色。管理员单独设一个小范围的组。3. 需要推送镜像的流水线单独建账号，放在另外的推送组，只授权给需要推送的组织；流水线用的访问密钥只交给流水线保存，不要发给个人，也不要写进代码仓库，定期轮换。命令：用开发人员的账号登录并拉取：docker login -u IAM用户名 -p 访问密钥 swr.cn-north-4.myhuaweicloud.comdocker pull swr.cn-north-4.myhuaweicloud.com/组织名/镜像名:标签验证方法：1. 开发账号 docker pull 能成功，说明拉取权限正常。2. 同一个账号执行 docker push，应被拒绝，返回 denied 或无权限的报错，这就证明推送已被拦住。3. 用开发账号登录控制台，SWR 里能看到组织和镜像列表，但没有删除镜像、修改组织成员的入口，或操作时被拒绝。4. 把一个刚离职或调岗的测试账号移出用户组后，再登录应立即看不到组织内容。注意事项：1. 组织和仓库保持私有，不要为了图方便设成公开拉取，否则权限配置等于白做。2. 不要用主账号的访问密钥做日常拉取和推送，主账号密钥只做极少数管理操作。3. 不要把访问密钥写进 Dockerfile、代码仓库或聊天记录，流水线里用凭据管理保存。4. 人员变动时要同时处理两层：移出 IAM 用户组，也要移出 SWR 组织成员，只做一层会留下入口。5. IAM 策略与组织权限是叠加关系，任一层放宽都可能漏权限，改完后按上面验证方法实测一遍，不要只看配置页面就认为生效了。

结论：先别调 JVM 参数。137 是 SIGKILL，但 free 还有 6~8GB，说明杀进程的不是宿主机内存耗尽，而是某个 cgroup 的内存上限或构建进程自身的峰值。按下面顺序做一次“带证据”的复现，就能确定凶手是谁，而不是靠重跑碰运气。一、排查步骤：先分清三种 SIGKILL 来源1. 容器 / 构建步骤的 cgroup 内存超限：被杀的是 docker build 步骤所在的容器，宿主机内存充足也会杀。2. 内核 OOM killer：整机内存真的耗尽，dmesg 里会有 Killed process 记录。3. 构建工具自身峰值：maven 编译、解压依赖、打包镜像层的某一瞬间峰值超过 limit，随后内存又回落，所以 free 事后看是正常的。你描述的现象（约 1/5 失败、失败阶段不固定、重跑成功、换了更大的基础镜像后出现）最符合第 1 和第 3 种叠加：基础镜像变大 + 构建缓存增长，峰值偶尔撞上限。二、具体操作：加一节“证据采集”步骤在 docker build 之前，先在流水线里加一个 shell 步骤，把当时值写进构建日志（失败后无法回看，执行机可能已被回收）：cat /sys/fs/cgroup/memory.events 2>/dev/null || cat /sys/fs/cgroup/memory/memory.oom_controlcat /sys/fs/cgroup/memory.max 2>/dev/null; cat /sys/fs/cgroup/memory.current 2>/dev/nullfree -hdocker system dfdu -sh . 2>/dev/null; cat .dockerignore 2>/dev/null重点是 memory.events 里的 oom_kill 计数：下一次失败时如果 oom_kill 增加了，就是 cgroup 触发的 OOM；如果没有增加，再去看 dmesg。同时把构建日志打详细，定位死在哪一步：docker build --progress=plain -t 你的镜像名:tag . 2>&1 | tee build.log--progress=plain 会按顺序输出每一步，失败的 RUN 步骤一目了然。看 137 之前最后一行：如果停在 mvn compile / 解压依赖，是 maven 峰值；如果停在 Sending build context，是构建上下文过大。三、给 JVM 一个“不在场证明”在 MAVEN_OPTS 里加上堆转储参数：MAVEN_OPTS="-Xmx2g -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof"下次再失败：- 如果 /tmp 下生成了 heapdump.hprof，说明是 JVM 堆真的满了，再调 -Xmx 或查内存泄漏。- 如果没有生成，却还是 137，说明 JVM 堆没满，凶手在堆外：可能是 metaspace、线程栈、或构建进程的 native 内存峰值。另外限制 maven 的并行：构建命令改为 mvn -B -T 1 -DskipTests package，并把 -Xmx 从 2g 降到 1g，给 buildkitd 和 docker 层打包留出余量。四、降低峰值：缓存挂载 + 瘦身上下文1. Dockerfile 里 maven 阶段用缓存挂载，避免每次重新下载依赖：RUN --mount=type=cache,target=/root/.m2 mvn -B -DskipTests package2. 检查构建上下文大小：tar -cf - . | wc -c如果上下文几百 MB，先补 .dockerignore，至少排除：target/、.git/、node_modules/、*.log。上下文越大，docker build 打包发送时占用的内存和 IO 就越大。五、验证方法做完上面改动后，连续跑 5~10 次同一流水线，全部成功才算解决：1. 每次构建日志里 memory.events 的 oom_kill 不再增加。2. --progress=plain 日志能看到每一步正常结束，不再有无故中断。3. 构建耗时回到换基础镜像之前的大致水平，且不再出现偶发 137。如果 10 次里还有 1 次失败，把那次失败的 build.log、memory.events 输出和 heapdump 存在情况贴出来，再看是并行构建互相挤占，还是执行机上有其他任务在同时跑——托管执行机上多个构建并发时，峰值是叠加的。六、注意事项- docker build --memory 在 BuildKit 下基本不起作用，不要指望用它限流。- 托管执行机上可能没有权限看宿主机 dmesg，先以 memory.events 为准，它不需要宿主机权限。- 不要在生产构建上直接试参数，先在同一个流水线复制一份测试构建验证。- docker builder prune 能缓解缓存膨胀，但会让下次构建全量下载依赖，峰值反而可能更高，慎用。

结论：这是 ReadWriteOncePod 按设计生效的排他，不是驱动坏了。单块 EVS 同一时间只能被一个 Pod 挂载，旧 Pod 没完全退出、卷没 detach 之前，新 Pod 必然卡在 ContainerCreating。接受“先停后起”的停机窗口，是 RWOP 单副本的唯一正确预期；想不停机或多写者，只能换架构。一、排查步骤（先定位卡在哪一层）1. 确认旧 Pod 的真实状态，不要只看新 Pod 的事件：kubectl get pods -n -o widekubectl describe pod -n 看旧 Pod 是否处于 Terminating、是否卡在 preStop 或应用迟迟不响应 SIGTERM。2. 确认卷的占用记录：kubectl get volumeattachment | grep kubectl describe volumeattachment VolumeAttachment 还在，就说明卷尚未 detach，新 Pod 的 FailedAttachVolume 一定会持续出现。3. 确认 CSI 驱动已在执行 RWOP：kubectl get csidriver已经出现“独占生效 + FailedAttachVolume”，本身就证明当前驱动在执行 RWOP 排他；如果驱动完全不支持 RWOP，不会出现这种明确的拦截。二、具体操作（按顺序做，不要并行改多个变量）1. 动手前先给 EVS 做快照或备份，低峰期操作。2. 缩短旧 Pod 的退出等待，但要以应用能完成停写、刷盘为前提，例如把 terminationGracePeriodSeconds 从 60 改为 15 秒。不要直接设为 0，也不要用 --force --grace-period=0 强删 Pod，卷还挂着时强删可能导致未落盘的数据丢失。3. 给容器加 preStop 做优雅停写，例如先停止接收新请求、刷盘后再退出；但要明确：preStop 只在 Pod 终止流程内执行，kubelet 只有在 Pod 完全终止后才会卸载卷，preStop 本身不能让新 Pod 提前 attach。4. 更新时观察 detach 再观察新 Pod：kubectl get pods -n -wkubectl get volumeattachment | grep 等旧 Pod 完全消失、VolumeAttachment 记录消失后，新 Pod 才能正常挂载；如果用 Deployment，把更新策略改为 Recreate，先停旧 Pod、等卷 detach，再建新 Pod。5. 针对你的场景（StatefulSet、OrderedReady、副本 1）：保持 OrderedReady，滚动更新时不要手动并行建 Pod；新序号 Pod 出现的前提也是旧 Pod 完全终止，顺序不能跳过。三、验证方法1. kubectl get pods -n 里新 Pod 的 STATUS 为 Running，READY 为 1/1，且 RESTARTS 不再增长。2. kubectl get events -n --sort-by=.lastTimestamp 里不再出现新的 FailedAttachVolume。3. 进容器确认数据盘真实可用：kubectl exec -it -n -- shdf -h /datals -l /data并做一次业务写入后重新读取，确认数据可读、可写。四、注意事项1. 不要手动删除 VolumeAttachment 对象来“抢卷”，也不要改 PVC 的 accessModes 就地生效——RWOP 是一开始建 PVC 时的模式，改模式必须重建 PVC。2. 多副本共享数据一开始就不该用 EVS；换 SFS（RWX）后，SFS 只提供多 Pod 同时挂载，不保证多个写者同时写同一文件的一致性，一致性要靠应用层解决（单写者、文件锁、分片、数据库事务），不要依赖共享文件系统本身。3. CSI 驱动版本不要凭感觉猜：先在测试集群验证驱动升级与当前 CCE 版本的兼容性，再在低峰期升级生产集群。一句话：RWOP 单副本 EVS，先停后起是设计使然；要不停机或多写者，就换架构，不要在 RWOP 上硬凑。

结论：先按业务类型定下限，再按实测数据定规格，最后用弹性与计费方式控成本。 排查步骤：1. 先分清业务类型。Web 应用、数据库、计算密集、内存密集对 CPU、内存、磁盘 I/O 的需求完全不同，选型要先看瓶颈在哪一层。2. 看现有监控。没有监控就先跑一周基线：CPU 使用率、内存使用率、磁盘 I/O、网络带宽的峰值和均值都要有。3. 区分峰值与均值。只按均值选型，高峰会卡；只按峰值选型，平时浪费。峰值持续时间短的，用弹性伸缩补；峰值持续时间长的，才升固定规格。4. 再看计费方式。长期稳定运行的选包年包月，波动大、临时任务选按量付费，潮汐业务可以结合弹性伸缩。 具体操作与命令：在现有实例上先跑基线，再决定规格： nprocfree -hdf -huptimesar -u 1 5sar -r 1 5iostat -x 1 5 nproc 看核数，free -h 看内存，sar -u 看 CPU 利用率，sar -r 看内存，iostat -x 看磁盘等待与利用率。如果 CPU 长期超过 70% 且业务延迟上升，先升 CPU；如果内存长期超过 80% 或出现 OOM，先升内存；如果磁盘 await 持续偏高，先看磁盘类型与 IOPS，而不是只升 CPU。 选型参考：- 轻量 Web、小程序后端：2 核 4 GiB 起步，先跑起来再按监控调整。- 业务高峰明显的应用：固定规格按峰值的 70% 左右选，剩余峰值用弹性伸缩或队列削峰。- 数据库：内存优先，优先保证工作集能放进内存，再看 CPU 与磁盘 IOPS。- 计算密集：CPU 优先，选计算优化型，避免用通用型硬扛。 验证方法：1. 升配或降配后，重新跑 nproc、free -h，确认系统看到新规格。2. 用与生产接近的并发压测一轮，记录响应时间、错误率、CPU 与内存曲线。3. 上线后观察一个完整业务周期，包括高峰时段，确认没有新的瓶颈。4. 对照账单，确认费用变化与预期一致，再决定是否保留新规格。 注意事项：- 升配通常需要重启，先安排变更窗口并确认备份可用。- 不要把规格选型当成一次性工作，业务量变化后要定期复核。- 规格之外，先检查应用上限：连接池、线程数、JVM 堆等没改，升配效果会打折。- 成本控制靠监控与弹性，不是靠一直选最小规格；性能兜底靠压测与余量，不是靠一直选最大规格。

结论：这两个问题要分开看。第一，SSH 远程开发何时在鸿蒙版上线，帖子里没有官方时间，我也无法替官方承诺日期，先按当前版本暂未提供该入口来处理，不要干等；第二，终端提示没有安装 git，大概率是 CodeArts 内置终端的 PATH 与系统终端不一致，这是可以当场修好的配置问题，先修这一项，日常开发就能先恢复。 排查步骤：1. 在鸿蒙版 CodeArts 的内置终端里依次执行 echo $SHELL、command -v git、echo $PATH，确认三点：当前终端是不是 zsh、git 是否在 PATH 里、PATH 与系统终端是否一致。2. 再打开系统自带终端执行同样的三条命令，两边对照；如果系统终端能找到 git 而 CodeArts 终端找不到，问题就锁定在 CodeArts 终端环境，不是 git 本身没装。3. 在 CodeArts 里打开命令面板，搜索 Remote-SSH、远程，看有没有远程开发入口；没有入口即说明当前版本尚未提供，不要反复重装去找入口。 操作/命令：1. 先拿到 git 的真实路径：在系统终端执行 command -v git，记下输出。2. 在系统终端执行下面两行，把 git 所在目录自动追加到 zsh 启动文件（不需要手抄路径，命令自己取真实路径）：cp ~/.zshrc ~/.zshrc.bakgit_dir=$(dirname "$(command -v git)"); echo "export PATH=\"$git_dir:\$PATH\"" >> ~/.zshrc3. SSH 的过渡方案：在 CodeArts 内置终端直接用 ssh user@远程主机 登录远程机执行命令；文件同步走 Git 仓库提交拉取，或用 scp 单向同步，例如 scp 本地文件 user@主机:远程目录。 验证：1. 在 CodeArts 里关掉旧终端、重新打开一个新终端（.zshrc 只对新终端生效），依次执行 git --version、command -v git、echo $SHELL，三项都有正常输出即算修好。2. 再执行 ssh -V 确认 SSH 客户端本身可用；然后回到命令面板确认有无 Remote-SSH 入口，有则可直接用，无则按上面的过渡方案走。 注意事项：1. 改 .zshrc 前先备份，上面命令里的第一行就是备份，改错可用 cp ~/.zshrc.bak ~/.zshrc 恢复。2. 不要把私钥路径或他人账号信息写进共享配置；SSH 私钥文件权限保持 600。3. 鸿蒙版与 Windows 版功能对齐的具体时间以官方发布说明为准；功能诉求建议同步向官方反馈渠道提一次，便于产品侧排期，本文只解决当下能先用起来的部分。

结论：排除专线、走公网的情况下，首选两边云厂商托管的 IPsec VPN 网关做 site-to-site 隧道；只有托管网关不支持、或要完全自控策略时，才在两边 ECS 上自建 strongSwan。不要用普通“翻墙式”VPN 客户端或单点拨号去承载 VPC 互访，那只能让一台机器上网，不能让两个网段三层互通。一、先确认两个前提，任何一个不满足，隧道建起来也 ping 不通1. 两边 VPC 网段不能重叠。例如 A 云是 10.0.0.0/16，B 云就不能也是 10.0.0.0/16，哪怕子网不同也不行。重叠只能改网段或做 NAT 映射，没有“调路由就能绕过”的办法。2. 两边都要有可用的公网出口：托管网关需要绑定弹性公网 IP，自建则需要两台带公网 IP 的 ECS，并且安全组放行 UDP 500、UDP 4500（NAT 穿透时用）。二、托管 IPsec VPN 的具体操作（以华为云一侧为例，对端云镜像做一遍）1. 在华为云创建 VPN 网关，绑定弹性公网 IP；再创建 VPN 连接，填对端网关的公网 IP、预共享密钥。2. 本端子网填华为云 VPC 里要互访的子网，对端子网填另一朵云 VPC 的子网；两边填法正好镜像，千万不要把本端、对端填反。3. IKE 策略和 IPsec 策略两边保持一致：建议 IKEv2，加密和认证算法两边选同一套，不要一边默认、一边自定义。4. 在两边 VPC 的路由表里各加一条路由：目的网段是对端 VPC 网段，下一跳指向 VPN 连接（或 VPN 网关）。只建隧道、不加路由，流量根本不会进隧道。5. 安全组和网络 ACL 放行对端网段：只放行“对方 VPC 网段”即可，不要为了省事放行 0.0.0.0/0。三、自建 strongSwan 时的关键点两边 ECS 各装 strongSwan，配置 site-to-site：左端填本端公网 IP 与本端子网，右端填对端公网 IP 与对端子网，预共享密钥两边一致；同样要在两边路由表和安全组里放行对端网段。OpenVPN 的 tun 模式也能做，但生产互联优先用 IPsec，兼容性和排障资料都更成熟。四、验证：按这个顺序查，不要只 ping 一下就下结论1. 先看两边 VPN 连接状态是不是“已建立”或“正常”；状态没起来，先查预共享密钥、公网 IP、IKE/IPsec 策略是否一致。2. 状态正常后，从 A 云一台 ECS ping B 云一台 ECS 的内网 IP，能通说明三层已打通；再用 traceroute 看路径是否经过隧道。3. 大包不通、小包通，多半是 MTU 问题：把隧道内 MTU 设到 1400 左右再试，并检查两边是否开了 TCP MSS 调整。五、收费：主要分三块，流量费才是大头1. 网关费：托管 VPN 网关按实例收费，两边各一个；自建则是两台 ECS 的计算费用。2. 公网 IP 与带宽费：网关绑定的弹性公网 IP、带宽按各云定价收取。3. 出流量费：跨云互访的流量按公网出方向计费，而且是双向都可能产生费用——A 访问 B 算 A 的出流量，B 回包算 B 的出流量。流量越大越要先估算，长期大流量、时延敏感的场景，还是回头评估专线或云连接的成本，不要只看网关月费便宜。注意事项：同属一朵云、只是不同 region 的互联，不要走公网 VPN，优先用该云的 VPC 对等连接或云连接，又便宜又稳定；跨云 VPN 只承载内网互访流量，不要把公网出口流量也绕进来，既费钱又不安全。

结论：先不要换控件。第一次能收号、第二次直接走到“本次服务结束”，说明问题大概率不在收号控件本身，而在第二次收号节点的状态、变量或分支：第二次节点没有真正进入收号，或者收号结果没有被正确保存和判断，流程直接走了超时/异常分支。密码修改流程能用，恰好说明要逐项对比两个流程的第二次节点，而不是只看控件名字。 一、排查步骤1. 先确认第二次节点到底有没有执行。在流程测试日志里找第二次查密节点的进入、提示播放、收号开始和收号结束记录；如果只有第一次节点的记录，说明流程在第一次之后就跳走了，重点查第一次节点的后续连线。2. 再确认第二次收号结果存到了哪个变量。第一次和第二次如果共用同一个变量，第二次赋值前要先确认变量是否被清空或被第一次的结果覆盖；截图里第一次是“查密第一次复合Cell”，第二次是“查密第二次复合Cell”，要核对第二次复合Cell的输出变量名，不要只看显示名。3. 对比收号参数。逐项对比两个流程第二次节点的：收号位数、超时时间、结束键、是否允许按键打断提示、提示音是否可打断、超时和失败分支指向哪里。任何一项不同，表现都可能是“输完就结束”。4. 查第一次节点的收尾动作。第一次输完密码后，是否有“结束服务”“挂机”或“返回主流程”的分支被误触发；第一次节点的成功分支、超时分支、失败分支要分别走一遍测试。 二、操作：按下面顺序改1. 给第二次收号单独建一个变量，不要复用第一次的变量；第二次复合Cell的输出指向这个新变量。2. 把第二次节点的超时时间先放宽到与第一次一致，结束键与第一次一致，提示音设为可打断；超时分支和失败分支先指向“重新收号”或“转人工提示”，不要直接指向“本次服务结束”。3. 在第二次节点前后各加一条日志打印：进入第二次节点、收到的按键、保存后的变量值；这样一次测试就能分清是“没进入”“没收到”还是“收到但没保存”。4. 改完后重新发布流程再测试，不要只在编辑器里点预览；流程发布状态不同，测试结果也可能不同。 三、验证1. 正常路径：第一次输密码通过，第二次输密码后应进入查密校验，而不是播报结束语。2. 异常路径：第二次超时不输入，应走到“重新收号”提示，而不是直接结束；第二次输错，应走到“密码错误”提示。3. 对照路径：用同一部电话、同一组密码，先跑密码修改流程，再跑当前流程，两次的第二次节点日志要能一一对应。 四、注意事项1. 不要把第一次和第二次的提示音、变量、分支复制后只改名字不改指向，复制节点最容易漏改输出变量和分支。2. 测试时不要只测一次成功路径，超时、输错、提前挂机这三种情况都要测一次。3. 如果日志里第二次节点根本没有进入记录，优先查第一次节点的连线和条件判断，不要先去改收号控件参数。