摘要：本文整理自阿里采集分析平台工程技术负责人 吴宝国 老师，在 Flink Forward Asia 2025 城市巡回深圳站中的分享。

Tips：关注「公众号」回复 FFA 2025 查看会后资料～

大家好，我是来自阿里集团平台技术部数据技术与产品部的吴宝国。今天非常荣幸能在这里跟大家分享我们在阿里内部大规模落地 Fluss 的一些实践经验。

首先简单介绍一下我们团队。我们团队主要负责集团内部统一的用户行为采集与分析平台，也就是大家常说的 A+ 平台。我们的核心职责是为手淘、钉钉、高德、饿了么等众多集团内应用提供端到端的用户行为数据采集、处理、分析及服务能力。

在底层，我们构建了覆盖 Web、小程序、APP（包括 Android、iOS、PC、IOT、鸿蒙、VR 等）以及服务端的全场景采集 SDK 矩阵。在此之上，我们不仅采集用户的行为日志（比如点击、曝光、滑动等），还会融合业务数据（如用户标签、商品信息、订单数据等），构建服务于整个集团的流量域数据公共层。最终，我们通过分析产品帮助业务团队洞察用户行为，驱动运营和产品决策，例如提升广告效果、优化用户体验等。

为了支撑这一庞大体系的实时性需求，我们引入了开源流存储系统 Fluss 作为核心的日志数据实时采集通道。接下来，我将从为什么选择 Fluss、如何保障大规模落地稳定性、具体业务实践案例以及未来规划四个方面展开分享。

一、为什么选择 Fluss？——解决两大核心痛点

在引入 Fluss 之前，我们的实时数据架构长期面临两个根本性挑战。

（1）成本高昂：行式消息队列导致资源浪费严重

我们过去主要依赖阿里内部的行式消息队列 TT（TimeTunnel）。以手淘的实时流量公共层为例，这张表包含了首页、闪购、搜索等多个业务的数据。每个下游业务（比如推荐系统）都需要一个独立的 Flink 作业来消费这张全量表，然后在作业内进行过滤，只保留自己关心的部分。

这种模式带来了三重成本问题：

• 存储与流量成本倍增：计费通常基于读写流量。即使每个业务只关心 1% 的数据，也需要为 100% 的全量数据付费。如果有 N 个业务，就要支付 N 倍的费用。
• Flink CU 资源浪费：Flink 作业需要消耗大量计算单元（CU）来读取、反序列化并丢弃无用的数据。很多时候，作业空跑不做任何逻辑处理，但依然产生高昂开销。
• 字段冗余读取：一张表可能包含数百个字段，但单个业务往往只需要其中几个。行式存储迫使消费者读取整行数据，造成巨大的 IO 和网络带宽浪费。

Fluss 通过其三大核心能力完美解决了上述问题：

• 多级分区（Multi-level Partitioning）：支持按业务、按场景等维度对数据进行精细划分。
• 过滤下推（Filter Pushdown）：消费者可以在订阅时声明过滤条件，数据在源头即可被精确过滤，避免全量拉取。
• 列式存储（Columnar Storage）：允许消费者只读取所需的字段，极大降低数据消费量和 Flink CU 消耗。

（2）湖流割裂：Lambda 架构的运维与一致性困境

业界经典的 Lambda 架构虽然能同时提供实时和离线视图，但维护两套独立的批处理和流处理链路，带来了开发、运维成本高企以及数据统计口径不一致等问题。

随着数据湖技术（如 Paimon、Hudi）的发展，湖仓一体架构成为主流，但它通常只能提供分钟级的数据新鲜度。对于搜索、推荐等要求秒级延迟的核心场景，我们仍需引入 Kafka 这类流式中间件，这实际上又回到了 Lambda 架构的老路，导致“湖”与“流”的割裂。

Fluss 的出现为我们提供了一个统一的解决方案：它既能作为高性能的流存储提供秒级数据新鲜度，又能通过其内置的分层存储（Tiering）能力无缝对接数据湖（如阿里内部的 Alake），真正实现了“湖流一体”，消除了双架构的痛点。

二、首次双11落地情况：大规模生产验证

2025 年的双 11 是 Fluss 在阿里集团的首次大促实战。目前，Fluss 已稳定服务于淘天（含通天塔、阿里妈妈等）、集团数据公共层、饿了么、淘宝闪购、高德、阿里影业等多个核心业务，核心场景主要集中在搜索、推荐、流量等。

在本次双十一期间，Fluss 展现了强大的承载能力：

• 数据量：4 PB/天
• TPS峰值：1 亿
• BPS峰值：100 GiB/s

这些数据充分证明了 Fluss 在大规模、高并发场景下的稳定性和可靠性。

三、集群部署架构

阿里集团内部的业务特点与云上有所不同，因此我们的部署架构也进行了针对性设计。

我们采用了“大集群 + 区域化部署”的模式。不同地域（如张北、上海）拥有独立的 Fluss 集群，而同一地域内的不同业务（如高德、钉钉、淘天）则通过数据库（DB）级别进行逻辑隔离。数据持久化在阿里自研的分布式文件系统 盘古 上，并通过 Tiering Service 同步至内部数据湖 Alake。

此架构的优势在于：

• 资源复用：多个业务共享一个大集群，提高资源利用率。
• 版本收敛：集群数量少，便于统一升级和管理。
• 运维集约：减少运维复杂度。

但也带来挑战：

• 运维压力：单一集群机器数量庞大，运维难度增加。
• 资源隔离：需要额外机制保障不同业务间的资源隔离。

为此，我们开发了独立的 Fluss Manager 来管理账号权限和集群配置，并在 VVP（Fluss 专有空间）中独立部署 Tiering Service（Flink Job），确保其稳定运行。

为了保障如此大规模集群的稳定运行，我们在多个方面进行了深度建设。

（1） 机架感知（Rack Awareness）

为防止物理机或机架故障导致数据丢失，我们实现了严格的副本放置策略。

• 机架感知前：三个副本可能分配在同一台物理机上的三个 Pod 上。一旦该物理机故障，将导致三副本数据丢失！
• 机架感知后：三副本规避策略，不允许分配在同机房-同机架-同物理机上。即使一台物理机故障，仍有两副本工作，保障数据安全。

（2） 监控告警体系

我们建立了覆盖全栈的立体化监控告警体系：

• 基础设施监控：包括物理机性能（磁盘容量、读写IO、网络流量、CPU、内存）和 Pod 性能。
• 服务端监控：监控 CoordinatorServer、Tablet Server 等核心组件的 Metrics 和日志。
• 远程存储监控：监控 Remote Storage (OSS/Pangu/HDFS) 的 QPS、读写延迟、带宽和容量。
• 数据湖监控：监控 Alake 的水位、读写情况，防止因数据灌入过载而影响湖仓。
• 告警服务：基于 Prometheus + SLS 的监控系统，实现及时告警。

四、稳定性建设

（1） 集群扩缩容（Rebalance Feature）

随着业务增长，集群需要动态扩容。我们实现了 Rebalance 功能：

1. AdminClient 发起 RebalanceRequest。
2. CoordinatorServer 收到请求后，GoalOptimizer 生成 RebalancePlan。
3. RebalanceExecutor 执行计划，通知 Tablet Server 迁移 Bucket Leader 和 ISR。
4. 新节点加入后，负载均衡，完成扩容。

（2） 表扩缩容（Bucket Rescale）

当单表流量增大时，可通过 ALTER TABLE 增加 Bucket 数量。

1. Client 发起 ALTER TABLE 命令。
2. Coordinator 计算新增 Bucket 的分布，并更新 Zookeeper 中的 TableAssignment。
3. Coordinator 通知所有 Tablet Server 创建新的 Bucket Replica。
4. Tablet Server 创建 Replica 并开始接收数据。

注意：客户端需重启以感知新分区，期间消费任务可能有短暂波动。

（3） 无感升级（Controlled Shutdown）

为保障升级过程对在线作业无明显影响，我们实现了无感升级：

1. 待下线 Tablet Server 发送 controlledShutdownRequest 给 Coordinator。

2. Coordinator 执行 

   • 步骤1：重选 Leader（新 Leader 上线）。
   • 步骤2：下线 Follower。
   • 步骤3：关闭其他资源。
3. 整个过程保证读写延迟波动小于 1 分钟，Leader 持续在线。

• K8s 侧支持：支持灰度升级、滚动升级和原地升级（kill pod 并秒级拉起），提升升级效率。

（4） Coordinator HA

Coordinator 是集群的“大脑”。我们为其构建了高可用架构：

• 主备选举：通过 Zookeeper 实现主备选举。
• 状态同步：副节点持续监听 ZK 节点变化，保持 CoordinatorContext 一致。
• 故障恢复：主节点宕机后，副节点自动选举为新主节点，并从 ZK 恢复上下文信息，确保元数据连续性。

（5） 压缩率与网络传输优化

为应对大规模集群的网络带宽瓶颈，我们集成了 ZSTD 列压缩算法。

• 实测效果：在淘系数据上，开启 ZSTD 后，存储空间下降 6 倍（8.88TB → 1.52TB）。
• 性能影响：写吞吐略有提升（3.33M/s → 3.51M/s），读吞吐基本持平（3.06M/s → 3.25M/s），CPU/内存开销可控。

（6） 上线前故障演练计划

上线前，我们执行了详尽的故障演练计划，模拟极端场景：

• CoordinatorServer：随机宕机、反复切换 leader、大量建表和分区。
• TableServer：随机宕机、Remote 存储堆积、Bucket 的 Replica 宕机。
• Client：读写流量压测、一致性测试、冷数据追数据延迟测试。
• 其他：网络拥塞、磁盘挂掉、Zookeeper 故障等。

通过这些演练，全面验证了系统的健壮性、容错能力和数据一致性。

五、湖流一体：统一架构的演进

在湖流一体这块，我们会直接从 Fluss Manager 发起“湖流一体表”的创建操作。创建完成后，会使用 Fluss 的生产账号（而不是业务自己的账号），在 Paimon 中为业务直接创建一张对应的 Paimon 表。

这张 Paimon 表与 Fluss 中的表在命名上完全一致，包括 Namespace 和 DB 名称都保持统一。这样一来，业务在 Paimon 侧可以给这张表打上“湖流一体表”的标记，在 Fluss 侧也能看到它是“湖流一体表”，对业务来说是一张“看起来统一”的表，但在底层实际上是两张独立的物理表。

数据同步方面，我们通过 Tailing Service 集群配合内部 Flink 集群，由生产账号将 Fluss 中的数据以分钟级或秒级的粒度同步到 Paimon。与此同时，在 Tailing Service 上做了一系列 Native 级别的优化，使得整体性能相较于通用的 Flink 接入方式（Flink Native）会更好一些。

六、业务实践案例与核心收益

Fluss 的落地为多个业务场景带来了显著收益，下面我将逐一介绍。

（1）淘宝数据平台：实时数仓重构

• 原架构：依赖行式消息队列（TT）和离线数仓（MaxCompute/ODPS），数据新鲜度在小时级。
• 新架构：采用 Fluss + Paimon 湖仓架构，数据新鲜度提升至秒级。

• 收益：

  • 替代行式消息队列，整体成本降低 40% 以上。
  • 基于 Fluss 的列更新特性，离线/实时数据回刷时只需更新变更字段，回刷成本大幅降低。
  • 简化了数据链路，下游 OLAP 引擎（如 StarRocks）可直接查询 Paimon 表。

（2）淘宝闪购：实时监控与加工

将流量实时 DWD 公共层写入 Fluss，并通过 Tiering Service 持久化到 Paimon。此架构既保障了秒级时效性，又支持高效的 OLAP 分析，真正实现了实时监控，产出效率远超旧版基于物化视图定时调度的方案。

（3）通天塔（AB实验平台）：降本增效

• 痛点：行式存储导致整行消费，资源消耗高（曝光表 44 个字段，平台仅需 13 个）；数据探查困难；大 State 作业运维复杂、不稳定。
• 方案：利用 Fluss 的列裁剪能力，结合 Paimon 存储和 StarRocks 查询。
• 收益：读 Fluss 的 Flink 作业 CPU 占用减少 59%，内存占用减少 73%，IO 减少 20%。同时，通过 KV 表的 Merge 引擎和 Delta Join 技术，解耦了作业与状态，提升了灵活性。

（4）A+ 采集分析平台：全链路优化

在流量公共层应用 Fluss 的多级分区能力，显著降低了下游消费的数据量，使得下游 Flink CU 消耗降低约 35%，全链路成本降低约 70%。

七、未来规划

展望未来，我们将从以下方向持续投入：

1. 扩大服务规模：将 Fluss 服务推广至更多集团业务，巩固其作为统一实时数据通道的地位。
2. 全面推进湖流一体：深化 Fluss 与 Paimon/Alake 的集成，打造更成熟、易用的湖流一体解决方案。
3. 追求更高性能：持续优化 Fluss 内核，在吞吐、延迟、资源利用率等方面达到业界领先水平。
4. 探索新场景：构建业界领先的 Agent 采集与评测一体化平台，为 AI Agent 在代码、电商、数据等场景的效果评估与优化提供数据基石。

🔥 阿里云流存储 Fluss 于 2026 年 1 月 13 日 正式开启免费公测

基于 Apache Fluss 打造的高性能列式流存储系统，具备毫秒级读写响应、实时数据更新及部分字段更新能力，可替换 Kafka 构建 面向分析的流式存储，结合 DLF（Paimon）等数据湖产品构建 湖流一体架构。

🎁 公测活动： 公测期间单用户可 免费使用2个集群，单个集群上限80 Core，如果您在使用过程中向我们提出改进建议或评测报告，我们将依据反馈内容的深度与质量，向优质测评者 赠送定制Fluss周边礼品。

流存储Fluss版公测说明：https://help.aliyun.com/zh/flink/realtime-fluss/product-overv...

复制链接或扫描下方二维码：https://survey.aliyun.com/apps/zhiliao/G-2wQFAuV

更多内容

活动推荐

复制下方链接或者扫描左边二维码

即可免费试用阿里云 Serverless Flink，体验新一代实时计算平台的强大能力！

了解试用详情：https://free.aliyun.com/?productCode=sc

在实际的文档处理场景中，PDF 页面方向不正确是一个非常常见的问题，例如扫描文件方向颠倒、合并文档后页面方向混乱等。借助 Python，我们可以通过代码实现对 PDF 页面旋转角度的精确控制，并支持读取当前旋转状态和批量操作。

本文使用的方法需要用到 Free Spire.PDF for Python，可通过 pip 安装：pip install spire.pdf。

本文将介绍：

• 如何旋转 PDF 的指定页面
• 如何读取页面当前的旋转角度
• 如何在保持原有方向的基础上进行增量旋转
• 如何批量旋转 PDF 中的所有页面

一、PDF 页面旋转的基本原理

在 Spire.PDF 中，每个页面都对应一个 PdfPageBase 对象，其 Rotation 属性用于描述页面的旋转状态。
该属性的类型为 PdfPageRotateAngle 枚举，内部以整数值表示当前旋转方向：

需要注意的是：

• PDF 页面旋转角度不会达到 360° 或以上
• Rotation.value 可安全转换为 int 用于逻辑判断
• 页面旋转是状态覆盖，而不是累加，需要自行计算新角度

二、旋转指定页面（基础示例）

下面的示例演示了如何旋转 PDF 中的某一页，并对参数进行合理校验：

from spire.pdf.common import *
from spire.pdf import *


def rotate_pdf_page(input_pdf_path, output_pdf_path, page_index, rotation_angle):
    """
    旋转PDF文档中指定页面。

    Args:
        input_pdf_path (str): 输入PDF路径
        output_pdf_path (str): 输出PDF路径
        page_index (int): 页面索引（从0开始）
        rotation_angle (int): 旋转角度（90 / 180 / 270）
    """
    document = PdfDocument()
    try:
        document.LoadFromFile(input_pdf_path)

        if page_index < 0 or page_index >= document.Pages.Count:
            raise IndexError("页面索引超出范围")

        page = document.Pages[page_index]

        if rotation_angle == 90:
            page.Rotation = PdfPageRotateAngle.RotateAngle90
        elif rotation_angle == 180:
            page.Rotation = PdfPageRotateAngle.RotateAngle180
        elif rotation_angle == 270:
            page.Rotation = PdfPageRotateAngle.RotateAngle270
        else:
            raise ValueError("仅支持 90、180、270 度旋转")

        document.SaveToFile(output_pdf_path)

    finally:
        document.Close()

该方法适用于明确知道目标角度的场景，例如“统一将第 1 页旋转为 90°”。

以下是旋转效果预览：

三、获取 PDF 页面当前的旋转角度

在实际应用中，我们往往需要先判断页面当前方向，再决定是否旋转或如何旋转。

page = document.Pages[0]
current_rotation = page.Rotation.value

print(f"当前页面旋转状态：{current_rotation}")

current_rotation 的返回值为 0~3 的整数，对应关系如下：

rotation_map = {
    0: 0,
    1: 90,
    2: 180,
    3: 270
}

print(f"当前角度为 {rotation_map[current_rotation]}°")

这种方式非常适合用于：

• 判断扫描 PDF 是否方向正确
• 根据现有方向进行“补偿旋转”
• 过滤无需处理的页面

四、在原有角度基础上进行增量旋转

如果直接设置 page.Rotation，原有旋转状态会被覆盖。
若希望在当前角度基础上再旋转 90°，可以采用如下方式：

current_value = page.Rotation.Value
new_value = (current_value + 1) % 4

rotation_enum_map = {
    0: PdfPageRotateAngle.RotateAngle0,
    1: PdfPageRotateAngle.RotateAngle90,
    2: PdfPageRotateAngle.RotateAngle180,
    3: PdfPageRotateAngle.RotateAngle270,
}

page.Rotation = rotation_enum_map[new_value]

这种写法的优势在于：

• 不依赖具体角度数值
• 自动处理 270° → 0° 的回绕逻辑
• 适合“顺时针旋转一圈”的业务需求

五、批量旋转 PDF 中的所有页面

当需要对整份文档进行统一处理时，可以直接遍历 Pages 集合：

def rotate_all_pages(input_pdf_path, output_pdf_path, rotation_angle):
    document = PdfDocument()
    try:
        document.LoadFromFile(input_pdf_path)

        for i in range(document.Pages.Count):
            page = document.Pages[i]
            if rotation_angle == 90:
                page.Rotation = PdfPageRotateAngle.RotateAngle90
            elif rotation_angle == 180:
                page.Rotation = PdfPageRotateAngle.RotateAngle180
            elif rotation_angle == 270:
                page.Rotation = PdfPageRotateAngle.RotateAngle270

        document.SaveToFile(output_pdf_path)
    finally:
        document.Close()

如果需要只旋转方向不正确的页面，可以结合 Rotation.Value 进行条件判断，从而避免不必要的修改。

六、常见注意事项与实践建议

1. 页面索引从 0 开始
   第 1 页的索引为 0，这一点在批量处理时尤其容易忽略。
2. Rotation 是页面属性，不影响内容坐标
   旋转的是页面显示方向，而非重新排版内容。
3. 不要假设 PDF 初始角度一定为 0
   很多扫描 PDF 天生就带有旋转信息。
4. 批量操作建议一次性保存
   避免在循环中频繁调用 SaveToFile，提升性能。

结语

通过 Spire.PDF for Python，PDF 页面旋转已经不再是复杂操作。
无论是简单的单页方向修正，还是基于当前角度的智能批量处理，都可以通过 page.Rotation 与 Rotation.Value 实现精细控制。

在自动化文档处理、扫描文件修正、企业级 PDF 流程中，这类能力往往是不可或缺的基础组件。

如果你拥有一个纯净的 Ubuntu 22.04 环境，想要一次性配置好“AI 全家桶”开发环境，最稳妥、最标准的方法是遵循 NVIDIA 网络仓库安装流程。

这套流程不仅会安装编译器（nvcc），还会安装驱动（Driver）、数学库（cuBLAS/cuDNN）以及开发工具，确保你后续安装 flash-attn、vLLM 或 DeepSpeed 时一马平川。

第一步：基础环境准备

首先确保系统有基础的下载和编译工具：

sudo apt update
sudo apt install -y build-essential charts-common wget curl git

第二步：配置 NVIDIA 官方仓库 (最关键)

通过官方提供的 cuda-keyring，让 apt 能够获取到所有 AI 相关的专用包。

# 1. 下载官方密钥配置包
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-keyring_1.1-1_all.deb

# 2. 安装密钥配置包
sudo dpkg -i cuda-keyring_1.1-1_all.deb

# 3. 更新仓库索引
sudo apt update

第三步：一键安装 CUDA + 驱动 + cuDNN

在纯净环境下，你可以直接安装 cuda 完整包，它会自动帮你匹配并安装最合适的显卡驱动。

# 安装 CUDA 完整版（包含驱动、Toolkit、示例、NVCC 等）
sudo apt -y install cuda

# 安装深度学习必备的 cuDNN 库
sudo apt -y install libcudnn9-cuda-12

注：由于我们正处在 2026 年，如果系统提示找不到 libcudnn9，可以尝试 sudo apt install libcudnn-cuda-12 来获取最新的兼容版本。

第四步：永久配置环境变量

安装在 /usr/local/cuda 的工具如果不加进 PATH，系统是识别不到 nvcc 的。

# 将配置写入当前用户的 .zshrc (如果是 bash 则改为 .bashrc)
echo 'export CUDA_HOME=/usr/local/cuda' >> ~/.zshrc
echo 'export PATH=$CUDA_HOME/bin:$PATH' >> ~/.zshrc
echo 'export LD_LIBRARY_PATH=$CUDA_HOME/lib64:$LD_LIBRARY_PATH' >> ~/.zshrc

# 立即生效
source ~/.zshrc

第五步：验证安装

运行以下两条命令，如果都能看到信息，说明你的 AI 塔基已经打好了：

1. nvidia-smi：检查显卡驱动和硬件状态。
2. nvcc --version：检查 CUDA 编译器是否就绪。

进阶：针对 AI 开发的额外补充

为了让你以后跑模型更顺滑，建议顺手装上这几个库：

1. NCCL（多显卡通信库，分布式训练必装）：

   sudo apt install libnccl2 libnccl-dev
   

2. NVML（监控库）：通常已随驱动安装。

总结你的“一键式”清单：

1. dpkg -i cuda-keyring... (换源)
2. apt install cuda (装驱动+工具链)
3. apt install libcudnn... (装深度学习加速库)
4. export PATH... (设环境变量)

当你完成这些后，再去你的虚拟环境中安装 flash-attn，它就会自动找到 nvcc 并开始愉快的编译了。需要我帮你写一个自动执行这些步骤的 .sh 脚本吗？

家庭网络如何获取到公网IPv6

OpenWrt 作为二级路由时 IPv6 故障排查与配置总结报告

背景

基于笔者的实战经验总结而来.
供参考.
适用于 iStoreOS 和 openwrt.
版本是: 24.10

1. 问题概述

初始状态

• 网络拓扑：电信光猫（拨号主路由） → iStoreOS/OpenWrt（二级路由） → 终端设备（PC/手机）。
• 核心问题：终端设备通过 iStoreOS/OpenWrt无法获得 IPv6 互联网连接，但直接连接光猫或通过另一台普通二级路由则正常。
• 关键限制：无法调整电信光猫的任何设置。(电信不让, 调了也可能被远程调回去...)

根本原因分析

在光猫拨号并已启用 IPv6 的网络中，光猫本身是 IPv6 的路由通告（RA） 和 DHCPv6 服务器。iStoreOS/OpenWrt 作为二级路由，其正确的角色应是一个 “透明中继” ，负责将光猫下发的 IPv6 信息原样转发给内网设备，而非自己充当服务器。默认的 iStoreOS/OpenWrt 配置（LAN 口为“服务器模式”）会尝试自行分配 IPv6，导致与上层冲突，使终端设备无法获得有效的公网 IPv6 地址或路由。

2. 排查与解决流程

整个排查过程遵循了从基础到深入、从配置到服务的逻辑，下图清晰地展示了核心的诊断路径与解决步骤：

flowchart TD
    A[问题：通过OpenWrt无IPv6<br>但直连光猫正常] --> B{检查OpenWrt WAN口状态}
    
    B --> C{WAN口是否获取到<br>公网IPv6地址？<br>（240e:/2408:开头）}
    C -- 是 --> D[核心问题：LAN口配置模式错误]
    C -- 否 --> E[需检查物理连接与光猫IPv6服务]
    
    D --> F[关键修复：修改LAN口DHCPv6设置]
    F --> G[将模式从“服务器”改为“中继/混合”]
    G --> H[并勾选“始终通告默认路由”]
    
    H --> I{终端设备是否获得<br>公网IPv6地址？}
    I -- 否 --> J[深入排查]
    I -- 是 --> K{IPv6网络连通性测试<br>（如 test-ipv6.com）}
    
    subgraph J [深入排查步骤]
        J1[检查并清空ULA前缀]
        J2[确认关闭IPv6 DNS过滤]
        J3[检查防火墙规则<br>（关闭WAN口IP动态伪装）]
        J4[重启odhcpd服务<br>清理旧地址]
    end
    
    J --> I
    K -- 失败 --> L[进行端到端Ping测试<br>定位中断环节]
    L --> M[根据测试结果<br>调整防火墙或MTU]
    K -- 成功 --> N[🎉 问题解决]

    style A stroke:#f66,stroke-width:2px
    style N stroke:#0a0,stroke-width:2px

各阶段关键操作与指令

1. 信息收集阶段

• 检查 iStoreOS/OpenWrt WAN 口：确认其通过 DHCPv6 协议获取到了电信的公网 IPv6 地址（240e:3a3:...），证明上游信号正常。如下图:

  

• 检查 iStoreOS/OpenWrt LAN 口配置：发现其 路由通告 和 DHCPv6 服务 均处于 “服务器模式”，这是问题的根源。如下图:

  

• 检查其他设置：发现 IPv6 ULA 前缀 未清空，且 过滤 IPv6 AAAA 记录 被勾选，这些都会干扰正常使用。

  

  

2. 核心配置修正阶段

• 将 LAN 口 DHCPv6 设置为中继：将 路由通告服务 和 DHCPv6 服务 改为 “中继模式” 或 “混合模式”。修正后如下:

  

• 清空 ULA 前缀：在 全局网络选项 中删除自动生成的 ULA 前缀（fdd5:...），防止其干扰公网地址分配。

  

• 允许 IPv6 DNS 解析：在 DHCP/DNS 高级设置中，取消勾选 “过滤 IPv6 AAAA 记录”。

  

• 调整防火墙：在 防火墙 设置中，确保 wan 区域的 IP动态伪装（NAT） 被取消勾选，以减少对 IPv6 流量的潜在干扰。

  

3. 服务应用与调试阶段

• 通过 SSH 或 TTYD 终端执行命令，重启负责 IPv6 的服务并清理旧地址：

  /etc/init.d/odhcpd restart
  ip -6 addr flush dev br-lan scope global

• 关键缺失项的发现：尽管终端设备获得了公网 IPv6 地址（240e:...），但 ipconfig /all 显示缺少 IPv6 默认网关。这直接导致数据包无法路由出去。这时候我的电脑显示如下:

  连接特定的 DNS 后缀 . . . . . . . : lan
     IPv6 地址 . . . . . . . . . . . . : 240e:3a3:xxxx
     IPv6 地址 . . . . . . . . . . . . : fdd5:3075:xxx
     临时 IPv6 地址. . . . . . . . . . : 240e:3a3:xxx
     临时 IPv6 地址. . . . . . . . . . : fdd5:3075:xxx
     本地链接 IPv6 地址. . . . . . . . : fe80::1ba8:xxx
     IPv4 地址 . . . . . . . . . . . . : 192.168.3.246
     子网掩码  . . . . . . . . . . . . : 255.255.255.0
     默认网关. . . . . . . . . . . . . : 192.168.3.1 (缺少 **IPv6 默认网关**)

  访问 <test-ipv6.com> 结果:

  你的公网 IPv4 地址是 x.x.x.x
  
  
  你的运营商（ISP）是 CHINANET-BACKBONE xxxx
  
  
  没有检测到 IPv6 地址 [更多信息]
  
  
  你只接入了 IPv4 互联网，不能访问纯 IPv6 网站。
  
  
  可向运营商咨询如何使用 IPv6，实现最佳的网络性能。 [更多信息]
  
  
  你的 DNS 服务器（可能由运营商提供）已经接入 IPv6 互联网了

4. 最终解决

• 返回 iStoreOS/OpenWrt LAN 口 DHCPv6 设置，找到并勾选 “始终通告默认路由” 选项。如下图:

  

• 保存应用后，终端设备立即获得了正确的 IPv6 默认网关（fe80::...），IPv6 互联网连接完全恢复。如下图:

  DHCPv6 IAID . . . . . . . . . . . : 10483xxxxx
     DHCPv6 客户端 DUID  . . . . . . . : 00-01-00-01-26-xxxxx
     DNS 服务器  . . . . . . . . . . . : 192.168.3.1
                                         fe80::xxxxxx%28
                                         240e:3a3:xxxxx
                                         fdd5:xxxxxx

  访问 <test-ipv6.com> 结果:

  你的公网 IPv4 地址是 xxxxx
  
  
  你的公网 IPv6 地址是 240e:3a3:xxxxx
  
  
  你的运营商（ISP）是 CHINANET-BACKBONE xxxx
  
  
  你已接入 IPv6，因此我们增加了一个标签页，显示你能否访问其他 IPv6 网站。[更多信息]
  
  
  你的 DNS 服务器（可能由运营商提供）已经接入 IPv6 互联网了。
  IPv6 状况评分
  10/10    此分数表示你的系统对 IPv6 的支持程度和稳定性
  点击查看 测试数据

3. 最终有效配置清单（iStoreOS/OpenWrt LuCI 界面）

4. 核心原理总结

1. 中继 vs 服务器：在无法控制主路由（光猫）的拓扑中，二级路由的 IPv6 必须使用 “中继” 模式。它像一座桥梁，只传递信息，不自行决定。
2. 地址分配顺序：系统会优先使用公网 IPv6 地址（GUA）。只有当中继失败、无法收到公网前缀时，设备才会退而求其次地使用 ULA 本地地址（fd 或 fdd 开头）。初期获得的 fdd5: 地址正是中继失败的标志。
3. 路由通告的重要性：IPv6 不仅依赖地址，更依赖路由。“始终通告默认路由” 选项确保路由器告诉内网设备：“我是你们通往 IPv6 互联网的出口”。缺少这一步，设备有地址也无法上网。
4. 防火墙差异：IPv6 的设计更倾向于端到端的直接通信，因此其防火墙策略与 IPv4（普遍使用NAT）有较大不同，通常无需也不建议对 IPv6 使用“动态伪装”（NAT）。

5. 经验与建议

1. 排查顺序：遵循 “先 WAN 后 LAN，先地址后路由” 的原则。先确认上级有信号（WAN口有公网IP），再排查内部转发（LAN口中继配置），最后检查路由和防火墙。
2. 配置备份：在 iStoreOS/OpenWrt 中，一旦配置成功，建议立即通过 “系统” -> “备份/升级” 生成一个备份文件。未来升级或重置后可以快速恢复。

3. 测试工具：善用以下工具进行精准定位：

   • ipconfig /all 或 ifconfig：查看本地地址和网关。
   • ping -6 <目标>：测试 IPv6 连通性。
   • test-ipv6.com：一站式综合测试。
4. 潜在优化：如果网络稳定，可以考虑在 LAN 口的 IPv6 设置中，将 路由通告服务 和 DHCPv6 服务 从 混合模式 改回更纯粹的 中继模式，以减少 iStoreOS/OpenWrt 本身的参与度，理论上有更好的稳定性。

通过以上步骤，笔者成功地在一个受限制的网络环境中，将 iStoreOS/OpenWrt 配置为了一个合格的 IPv6 中继节点，使所有内网设备都能无缝接入 IPv6 互联网。这套方法对于任何品牌的光猫（桥接或路由模式）下使用 iStoreOS/OpenWrt 作为二级路由的情况，都具有普遍的参考价值。