深海游弋的鱼 – 默默的点滴

商用密码32款认证产品、功能及认证依据详细介绍

为贯彻落实《中华人民共和国密码法》,建立完善商用密码产品认证体系，市场监管总局、国家密码管理局根据《国家密码管理局市场监管总局关于调整商用密码产品管理方式的公告》（第39号）分别于2020年、2022年及2025年连续发布三次商用密码产品目录，相关商用密码认证检测均依据此目录进行产品检测、认证。

以下是截止2025年3月27日，全量商用密码产品门类/目录，看看哪些是大家所了解和擅长的密码产品，具体如下：

第一批商用密码产品名录

市场监管总局国家密码管理局于2020年5月11日发布《商用密码产品认证目录（第一批）》，具体如下：

1、智能密码钥匙

产品名称：智能密码钥匙
功能描述：实现密码运算、密钥管理功能的终端密码设备，一般使用 USB 接口形态。
认证依据：

1）GM/T 0027《智能密码钥匙技术规范》

2）GM/T 0028《密码模块安全技术要求》

2、智能 IC 卡

产品名称：智能 IC 卡
功能描述：实现密码运算和密钥管理功能的含 CPU 的集成电路卡，包括应用于金融等行业领域的智能 IC 卡。
认证依据：

1）GM/T 0028《密码模块安全技术要求》

2）GM/T 0041《智能 IC 卡密码检测规范》

3、POS/ATM/多功能/互联网终端密码应用系统

产品名称：POS 密码应用系统、ATM 密码应用系统、多功能密码应用系统、互联网终端
功能描述：为金融终端设备提供密码服务的密码应用系统。
认证依据：

1）GM/T 0028《密码模块安全技术要求》

2）JR/T 0025-2018《中国金融集成电路 (IC) 卡规范第 7 部分：借记贷记应用安全规范》

4、PCI-E/PCI 密码卡

产品名称：PCI-E/PCI 密码卡
功能描述：具有密码运算功能和自身安全保护功能的 PCI 硬件板卡设备。
认证依据：

1）GM/T 0018《密码设备应用接口规范》

2）GM/T 0028《密码模块安全技术要求》

3）《PCI 密码卡技术规范》

5、IPSec VPN 产品 / 安全网关

产品名称：IPSec VPN 产品 / IPSec VPN 安全网关
功能描述：基于 IPSec 协议，在通信网络中构建安全通道的设备。
认证依据：

1）GM/T 0022《IPSec VPN 技术规范》

2）GM/T 0023《IPSec VPN 网关产品规范》

3）GM/T 0028《密码模块安全技术要求》

6、SSL VPN 产品 / 安全网关

产品名称：SSL VPN 产品 / SSL VPN 安全网关
功能描述：基于 SSL/TLS 协议，在通信网络中构建安全通道的设备。
认证依据：

1）GM/T 0024《SSL VPN 技术规范》

2）GM/T 0025《SSL VPN 网关产品规范》

3）GM/T 0028《密码模块安全技术要求》

7. 安全认证网关

产品名称：安全认证网关
功能描述：采用数字证书为应用系统提供用户管理、身份鉴别、单点登录、传输加密、访问控制和安全审计服务的设备。
认证依据：

1）GM/T 0026《安全认证网关产品规范》

2）GM/T 0028《密码模块安全技术要求》

8、密码键盘

产品名称：密码键盘
功能描述：用于保护 PIN 输入安全并对 PIN 进行加密的独立式密码模块。
认证依据：

1）GM/T 0028《密码模块安全技术要求》

2）GM/T 0049《密码键盘密码检测规范》

9、金融数据密码机

产品名称：金融数据密码机
功能描述：用于确保金融数据安全，实现 PIN 加密、MAC 产生与校验、签名验证等密码服务功能的设备。
认证依据：

1）GM/T 0028《密码模块安全技术要求》

2）GM/T 0045《金融数据密码机技术规范》

10、服务器密码机

产品名称：服务器密码机
功能描述：能独立或并行为多个应用实体提供密码运算、密钥管理等功能的设备。
认证依据：

1）GM/T 0028《密码模块安全技术要求》

2）GM/T 0030《服务器密码机技术规范》

11、签名验签服务器

产品名称：签名验签服务器
功能描述：为应用实体提供基于 PKI 体系的数字签名、验证签名等运算功能的服务器。
认证依据：

1）GM/T 0028《密码模块安全技术要求》

2）GM/T 0029《签名验签服务器技术规范》

12、时间戳服务器

产品名称：时间戳服务器
功能描述：基于公钥密码基础设施应用技术体系框架内的时间戳服务相关设备。
认证依据：

1）GM/T 0028《密码模块安全技术要求》

2）GM/T 0033《时间戳接口规范》

13、安全门禁系统

产品名称：安全门禁系统
功能描述：采用密码技术，确定用户身份和用户权限的门禁控制系统。
认证依据：

GM/T 0036《采用非接触卡的门禁系统密码应用技术指南》

14、动态令牌 / 动态令牌认证系统

产品名称：动态令牌 / 动态令牌认证系统
功能描述：生成并验证动态口令的载体与系统。
认证依据：

1）GM/T 0021《动态口令密码应用技术规范》

2）GM/T 0028《密码模块安全技术要求》（仅适用于动态令牌）

15、安全电子签章系统

产品名称：安全电子签章系统
功能描述：提供电子印章管理、电子签章/验章等功能的密码应用系统。
认证依据：

1）GM/T 0031《安全电子签章密码技术规范》

2）GM/T 0055《电子文件密码应用技术规范》

16、电子文件密码应用系统

产品名称：电子文件密码应用系统
功能描述：在电子文件全生命周期中提供密码运算、密钥管理等功能的应用系统。
认证依据：

GM/T 0055《电子文件密码应用技术规范》

17、可信计算密码支撑平台

产品名称：可信计算密码支撑平台
功能描述：为可信计算平台提供完整性、身份可信性和数据安全性密码支持。
认证依据：

1）GM/T 0011《可信计算密码支撑平台功能与接口规范》

2）GM/T 0012《可信计算可信密码模块接口规范》

3）GM/T 0028《密码模块安全技术要求》

4）GM/T 0058《可信计算 TCM 服务模块接口规范》

18、证书认证系统 / 证书认证密钥管理系统

产品名称：证书认证系统 / 证书认证密钥管理系统
功能描述：用于数字证书全生命周期管理与密钥对全过程管理的系统。
认证依据：

GM/T 0034《基于 SM2 密码算法的证书认证系统密码及其相关安全技术规范》

19、对称密钥管理产品

产品名称：对称密钥管理产品
功能描述：为密码应用系统生产、分发和管理对称密钥的系统及设备。
认证依据：

GM/T 0051《密码设备管理对称密钥管理技术规范》

20、安全芯片

产品名称：安全芯片
功能描述：含密码算法、安全功能，可实现密钥管理机制的集成电路芯片。
认证依据：

GM/T 0008《安全芯片密码检测准则》

21、电子标签芯片

产品名称：电子标签芯片
功能描述：采用密码技术，用于射频识别的电子识别信息芯片。
认证依据：

GM/T 0035.2《射频识别系统密码应用技术要求第 2 部分：电子标签芯片密码应用技术要求》

22、其他密码模块

产品名称：其他密码模块
功能描述：实现密码运算、密钥管理等功能的软件、硬件、固件及其组合。
认证依据：

GM/T 0028《密码模块安全技术要求》

//第二批商用密码产品名录

市场监管总局国家密码管理局于2022年7月14日发布《商用密码产品认证目录（第二批）》，具体如下：

23、可信密码模块

产品名称：可信密码模块
功能描述：为可信计算平台提供密码运算功能，具有受保护存储空间的硬件模块。
认证依据：

1）GM/T 0012《可信计算可信密码模块接口规范》

2）GM/T 0028《密码模块安全技术要求》

24、智能 IC 卡密钥管理系统

产品名称：智能 IC 卡密钥管理系统
功能描述：统一管理智能 IC 卡应用的密钥生命周期，为业务系统提供密钥服务。
认证依据：

GM/T 0107《智能 IC 卡密钥管理系统基本技术要求》

25、云服务器密码机

产品名称：云服务器密码机
功能描述：通过虚拟化技术为多租户提供密码服务的云形态服务器密码机。
认证依据：

1）GM/T 0028《密码模块安全技术要求》

2）GM/T 0104《云服务器密码机技术规范》

26、随机数发生器

产品名称：随机数发生器（软件 / 硬件）
功能描述：生成随机二元序列的程序或器件。
认证依据：

- 软件：

1）GM/T 0028《密码模块安全技术要求》

2）GM/T 0103《随机数发生器总体框架》

3）GM/T 0105《软件随机数发生器设计指南》

- 硬件：

1）GM/T 0028《密码模块安全技术要求》

2）GM/T 0078《密码随机数生成模块设计指南》

3）GM/T 0103《随机数发生器总体框架》

27、区块链密码模块

产品名称：区块链密码模块
功能描述：提供用户安全、共识安全、账本保护、隐私保护、身份认证等密码功能。
认证依据：

1）GM/T 0028《密码模块安全技术要求》

2）GM/T 0111《区块链密码应用技术要求》

28、安全浏览器密码模块

产品名称：安全浏览器密码模块
功能描述：集成浏览器内核与密码协议逻辑，保障浏览器场景下的密码安全。
认证依据：

1）GB/T 38636《信息安全技术传输层密码协议（TLCP）》

2）GM/T 0028《密码模块安全技术要求》

3）GM/T 0086《基于 SM9 标识密码算法的密钥管理系统技术规范》

4）GM/T 0087《浏览器密码应用接口规范》

//第三批商用密码产品名录

市场监管总局国家密码管理局于2025年3月27日发布《商用密码产品认证目录（第三批）》，具体如下：

29、基于 SM9 标识密码算法的密钥管理系统

产品名称：基于 SM9 标识密码算法的密钥管理系统
功能描述：实现标识密钥注册、生成、管理、发布的信息系统。
认证依据：

GM/T 0086《基于 SM9 标识密码算法的密钥管理系统技术规范》

30、PLC 控制器密码模块

产品名称：PLC 控制器密码模块
功能描述：为 PLC 控制器提供密钥存储、密码安全服务及与后台安全管理服务器交互功能的设备。
认证依据：

1）GM/T 0028《密码模块安全技术要求》

2）GM/T 0119《PLC 控制系统及 PLC 控制器密码应用技术规范》

31、DTLCP 密码模块

产品名称：DTLCP 密码模块
功能描述：基于数据报传输层密码协议（DTLCP），构建安全通信通道的设备。
认证依据：

1）GM/T 0028《密码模块安全技术要求》

2）GM/T 0128《数据报传输层密码协议规范》

32、SSH 客户端密码模块 / SSH 服务端密码模块

产品名称：SSH 客户端密码模块 / SSH 服务端密码模块
功能描述：基于 SSH 协议，提供安全远程登录和网络服务的设备。
认证依据：

1）GM/T 0028《密码模块安全技术要求》

2）GM/T 0129《SSH 密码协议规范》

参考链接

商用密码32款认证产品、功能及认证依据详细介绍

网页检测微信登录状态

现在很多网站、应用平台在登录的时候，都支持直接通过微信扫码登录。

最近我发现一个现象：以前需要扫二维码才能登录，而现在，如果你的电脑上已经运行了微信，它能直接检测到，然后点击一个按钮就可以实现登录了。

继续阅读网页检测微信登录状态

OpenBB的介绍以及如何使用OpenBB助力A股港股的金融数据分析

OpenBB 是一个开源的金融数据平台，旨在为投资者、分析师、研究人员和开发者提供免费、透明且易于使用的金融与宏观经济数据访问接口。它曾被认为是类似于彭博终端（Bloomberg Terminal）的功能性替代品，但完全开放源码，用户可以自由定制和扩展。

在一些文章中将 OpenBB 解释为 Open Bloomberg，这是个误解。尽管它常被视为“开源版彭博终端”，但其名称中的“BB”实际上源自黑莓公司的股票代码，而 OpenBB 的创始人此前曾在黑莓股票上亏损。

继续阅读OpenBB的介绍以及如何使用OpenBB助力A股港股的金融数据分析

macOS双频蓝牙鼠标失联问题

前置条件

MacBook Pro 2023-Apple M2 Pro （4能效核、8性能核、32GB内存、2TB磁盘）
macOS Sequoia 15.5
Lenovo ThinkLife 静音鼠标无线蓝牙版 WLM210

问题现象

蓝牙鼠标正常配对使用，刚刚开始使用正常的。但是过一阵子不使用蓝牙鼠标，或者鼠标电源调整成关闭状态，或者拔掉电池，大概率连接不上。需要在电脑上手工删除蓝牙连接，然后重新配对。

问题定位

刚开始猜测是鼠标使用的 南孚 TENAVOLTS 锂电池 DC-DC 降压电路释放的信号干扰到了蓝牙通信协议或者电压纹波导致芯片工作异常，在更换为普通的 1.5V 非充电电池之后，问题依旧复现。

无意中点击蓝牙设备列表，发现重新配对之后 Lenovo ThinkLife 的 MAC 地址变化了。这说明两者进行配对的时候使用了动态协商出来的临时 MAC 地址，没有使用设备的真实 MAC 地址。这样诱发一个问题，那就是鼠标需要记住这个动态协商出来的 MAC 地址，然后用这个地址进行通信。这样就能解释为什么拔掉电池多等一会儿，让设备完全放电，再插上电池很容易复现这个问题。因为长时间断电之后，设备上记录的协商 MAC 地址丢失了。

继续阅读macOS双频蓝牙鼠标失联问题

ARG to Rescue: Reuse Variables in Multistage Dockerfile

概要

在参照使用 Ubuntu 22.04使用Podman部署OpenGrok的详细教程进行 OpenGrok 部署的时候，其中的 Dockerfile 配置了两个独立的镜像来源。恰好这两个镜像来源都需要配置 PIP 国内镜像。于是思考如何在同一个 Dockerfile 存在两个镜像的场景下，如果共用一个变量。

研究了一阵，发现还是通过 ARG 变量实现上述想法。

具体说明参考下面的完整文章。

Introduction

The Docker ecosystem is rich with tools and best practices that streamline containerization. One of these practices is using multistage builds to create lean, efficient containers. However, as your Dockerfiles grow more complex, managing variables and maintaining readability can become a challenge. Enter the ARG instruction—your key to sharing variables across stages in a multistage Dockerfile. In this blog post, we’ll explore how ARG can simplify your Dockerfiles, enhance reusability, and maintain cleaner code.

Why Use Multistage Builds?

Multistage builds in Docker allow you to use multiple FROM statements in a single Dockerfile, creating separate stages that can be used to build a final image. This method is particularly useful for creating lightweight production images, as you can copy only the necessary artifacts from earlier stages. Here’s a quick example to illustrate:

# Stage 1: Build stage
FROM golang:1.16 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp .

# Stage 2: Production stage
FROM alpine:latest
COPY --from=builder /app/myapp /usr/local/bin/myapp
CMD ["myapp"]

# Stage 1: Build stage

FROM golang:1.16 AS builder

WORKDIR /app

COPY . .

RUN go build -o myapp .

# Stage 2: Production stage

FROM alpine:latest

COPY --from=builder /app/myapp /usr/local/bin/myapp

CMD ["myapp"]

In this simple example, the build stage compiles a Go application, and the production stage creates a minimal image containing only the compiled binary.

While multistage builds are powerful, they can introduce a common challenge: variable reuse. Suppose you need to use a specific version of an application or a common path across multiple stages. Without a way to share variables, you might end up duplicating code, leading to maintenance headaches and potential errors.

Here’s where ARG (argument) comes into play. The ARG instruction allows you to define variables that can be used throughout your Dockerfile, even across different stages.

Introducing ARG: The Basics

The ARG instruction defines a variable that users can pass at build time to customize the build process. Unlike environment variables (ENV), which are persisted in the image, ARG variables are only available during the build process and do not become part of the final image.

Let’s start with a basic example:

# Define the argument with a default value
ARG BASE_IMAGE=alpine:3.12

# Use the argument in the FROM instruction
FROM ${BASE_IMAGE}

RUN echo "This image is based on ${BASE_IMAGE}"

# Define the argument with a default value

ARG BASE_IMAGE=alpine:3.12

# Use the argument in the FROM instruction

FROM ${BASE_IMAGE}

RUN echo "This image is based on ${BASE_IMAGE}"

In this example, BASE_IMAGE is an argument that can be overridden when building the Dockerfile. The default value is alpine:3.12, but you could specify a different base image at build time:

docker build --build-arg BASE_IMAGE=ubuntu:20.04 -t custom-image .

1	docker build --build-arg BASE_IMAGE=ubuntu:20.04 -t custom-image .

The real power of ARG comes into play with multistage builds. To share ARG variables between stages, you need to redefine the ARG in each stage. Let’s look at a more advanced example:

# Define an argument for the Go version
ARG GO_VERSION=1.16

# Stage 1: Build stage
FROM golang:${GO_VERSION} AS builder
ARG GO_VERSION
WORKDIR /app
COPY . .
RUN go build -o myapp .

# Stage 2: Production stage
FROM alpine:latest
ARG GO_VERSION
RUN echo "Built with Go version ${GO_VERSION}"
COPY --from=builder /app/myapp /usr/local/bin/myapp
CMD ["myapp"]

# Define an argument for the Go version

ARG GO_VERSION=1.16

# Stage 1: Build stage

FROM golang:${GO_VERSION} AS builder

ARG GO_VERSION

WORKDIR /app

COPY . .

RUN go build -o myapp .

# Stage 2: Production stage

FROM alpine:latest

ARG GO_VERSION

RUN echo "Built with Go version ${GO_VERSION}"

COPY --from=builder /app/myapp /usr/local/bin/myapp

CMD ["myapp"]

In this Dockerfile, we define GO_VERSION as an argument at the top. By repeating ARG GO_VERSION in each stage, we make the argument available for use. Notice how the build stage uses GO_VERSION to specify the Go image, and the production stage echoes the Go version used.

Advanced Usage: Combining ARG with Environment Variables

You might find it useful to combine ARG with ENV to set environment variables conditionally based on build arguments. This can further enhance your Dockerfile’s flexibility.

Following example demonstrates the use of ARG and ENV to have a generic Dockerfile for a Turborepo application:

ARG APP_NAME="web"
ARG PNPM_HOME="/root/.local/share/pnpm"

FROM node:20-alpine AS base

FROM base AS builder
# Set working directory
WORKDIR /app

ARG APP_NAME
ARG PNPM_HOME
ENV PNPM_HOME=${PNPM_HOME}
ENV PATH="${PATH}:${PNPM_HOME}"

RUN corepack enable
RUN pnpm add -g turbo@2.0.4
COPY . .
# Collect all the necessary dependencies for the project
RUN turbo prune ${APP_NAME} --docker

# Add lockfile and package.json's of isolated subworkspace
FROM base AS installer

WORKDIR /app

ARG APP_NAME
ARG PNPM_HOME
ENV PNPM_HOME=${PNPM_HOME}
ENV PATH="${PATH}:${PNPM_HOME}"

RUN corepack enable

# First install dependencies (as they change less often)
COPY .gitignore .gitignore
COPY --from=builder /app/out/json/ .
COPY --from=builder /app/out/pnpm-lock.yaml ./pnpm-lock.yaml
RUN pnpm install

# Build the project and its dependencies
COPY --from=builder /app/out/full/ .
COPY turbo.json turbo.json

# Build the app
RUN pnpm turbo build --filter=${APP_NAME}

FROM base AS production

WORKDIR /app

ARG APP_NAME
ARG PNPM_HOME
ENV PNPM_HOME=${PNPM_HOME}
ENV PATH="${PATH}:${PNPM_HOME}"
ENV NODE_ENV="production"

RUN corepack enable

COPY --from=installer /app .

USER node

WORKDIR /app/apps/${APP_NAME}

CMD pnpm start

ARG APP_NAME="web"

ARG PNPM_HOME="/root/.local/share/pnpm"

FROM node:20-alpine AS base

FROM base AS builder

# Set working directory

WORKDIR /app

ARG APP_NAME

ARG PNPM_HOME

ENV PNPM_HOME=${PNPM_HOME}

ENV PATH="${PATH}:${PNPM_HOME}"

RUN corepack enable

RUN pnpm add -g turbo@2.0.4

COPY . .

# Collect all the necessary dependencies for the project

RUN turbo prune ${APP_NAME} --docker

# Add lockfile and package.json's of isolated subworkspace

FROM base AS installer

WORKDIR /app

ARG APP_NAME

ARG PNPM_HOME

ENV PNPM_HOME=${PNPM_HOME}

ENV PATH="${PATH}:${PNPM_HOME}"

RUN corepack enable

# First install dependencies (as they change less often)

COPY .gitignore .gitignore

COPY --from=builder /app/out/json/ .

COPY --from=builder /app/out/pnpm-lock.yaml ./pnpm-lock.yaml

RUN pnpm install

# Build the project and its dependencies

COPY --from=builder /app/out/full/ .

COPY turbo.json turbo.json

# Build the app

RUN pnpm turbo build --filter=${APP_NAME}

FROM base AS production

WORKDIR /app

ARG APP_NAME

ARG PNPM_HOME

ENV PNPM_HOME=${PNPM_HOME}

ENV PATH="${PATH}:${PNPM_HOME}"

ENV NODE_ENV="production"

RUN corepack enable

COPY --from=installer /app .

USER node

WORKDIR /app/apps/${APP_NAME}

CMD pnpm start

Key Points on Environment Variables in Multistage Builds

Environment Variables (ENV):
- Are specific to the stage where they are defined.
- Do not persist across stages.
- If you need an environment variable in multiple stages, you have to redefine it or pass it via ARG.
Build Arguments (ARG):
- Are defined once and can be passed to any stage by redeclaring them.
- Provide a way to share configuration details like versions or paths between stages.

Debugging ARG Variables

When working with ARG variables, you might run into issues where arguments aren’t passed correctly or variables aren’t set as expected. Here are some tips to help you debug:

Check Build Logs: Use docker build with the --progress=plain flag to get more detailed logs that can help identify where arguments are being used or missed.

docker build --progress=plain -t debug-image .

1

docker build --progress=plain -t debug-image .
Echo Variables: Add RUN echo statements to print the values of your ARG variables during the build process.

RUN echo "ARG BASE_IMAGE=${BASE_IMAGE}"

1

RUN echo "ARG BASE_IMAGE=${BASE_IMAGE}"
Use Default Values: Define sensible default values for your ARG variables to ensure that your build doesn’t fail if arguments are not provided.

Best Practices for Using ARG

Define ARG Variables Early: Place ARG instructions at the top of your Dockerfile to make them accessible in all stages.
Use Descriptive Names: Choose meaningful names for your arguments to make the Dockerfile easier to understand and maintain.
Avoid Secrets in ARG: Never use ARG to pass sensitive data like passwords or API keys, as they can be exposed in the Docker image history.

Conclusion

Using ARG to share variables across stages in a multistage Dockerfile can significantly improve your Docker builds’ maintainability and flexibility. Whether you’re building lightweight production images or dynamically configuring your builds, ARG provides a powerful tool to streamline and enhance your Dockerfile.

参考链接

搭建Docker Registry私有仓库

一、概述

本文将详细介绍如何在本地搭建一个 Docker 私有 Registry 仓库，并实现镜像的上传和管理。通过私有仓库，可以方便地在本地网络中存储和分发 Docker 镜像，提高开发和部署效率。

二、搭建步骤

（一）下载Docker Registry镜像

1. 命令：

# 此部分功能可以使用 Podman 替代

$ docker pull registry

# 此部分功能可以使用 Podman 替代

$ docker pull registry

2. 解析：

docker pull 是 Docker 的命令，用于从 Docker Hub 下载指定的镜像。
registry 是 Docker 官方提供的 Registry 镜像，用于搭建私有仓库。
默认情况下，docker pull 会下载最新版本的镜像（latest 标签）。

（二）启动Docker Registry容器

1. 命令：

# 此部分功能可以使用 Podman 替代


# Windows 系统
# docker machine ssh

# 创建映射目录
$ mkdir .docker.registry

$ docker run -d -p 5000:5000 --restart=always -v `pwd`/.docker.registry:/var/lib/registry --name registry registry

# Windows 系统
# exit

# 如果是 Windows 下的 Podman 则需要设置转发规则与防火墙
# 端口转发
# 参数说明  
#    v4tov4 : IPV4协议转发到IPV4协议
#    listenport : 对外暴露的端口，其他设备访问本机的端口
#    listenaddress : 监听地址，一般都是设置成 0.0.0.0 允许任何服务器访问服务
#    connectport : podman提供的Docker容器的对外暴露端口
#    connectaddress : podman提供的Docker容器的IP地址，由于podman每次重启都可能改变容器IP，但是本机都可以通过 127.0.0.1（localhost） 访问，所以干脆直接写成 127.0.0.1
# 特别注意的是，两个端口号不要写成一样的，否则会进入转发死循环
# netsh interface portproxy add v4tov4 listenport=6000 listenaddress=0.0.0.0 connectport=5000 connectaddress=127.0.0.1 

# 防火墙放行端口，只需要允许外部访问进入即可
# netsh advfirewall firewall add rule name="Docker Registry Port 6000" dir=in action=allow protocol=TCP localport=6000

# 此部分功能可以使用 Podman 替代

# Windows 系统

# docker machine ssh

# 创建映射目录

$ mkdir .docker.registry

$ docker run -d -p 5000:5000 --restart=always -v `pwd`/.docker.registry:/var/lib/registry --name registry registry

# Windows 系统

# exit

# 如果是 Windows 下的 Podman 则需要设置转发规则与防火墙

# 端口转发

# 参数说明

# v4tov4 : IPV4协议转发到IPV4协议

# listenport : 对外暴露的端口，其他设备访问本机的端口

# listenaddress : 监听地址，一般都是设置成 0.0.0.0 允许任何服务器访问服务

# connectport : podman提供的Docker容器的对外暴露端口

# connectaddress : podman提供的Docker容器的IP地址，由于podman每次重启都可能改变容器IP，但是本机都可以通过 127.0.0.1（localhost）访问，所以干脆直接写成 127.0.0.1

# 特别注意的是，两个端口号不要写成一样的，否则会进入转发死循环

# netsh interface portproxy add v4tov4 listenport=6000 listenaddress=0.0.0.0 connectport=5000 connectaddress=127.0.0.1

# 防火墙放行端口，只需要允许外部访问进入即可

# netsh advfirewall firewall add rule name="Docker Registry Port 6000" dir=in action=allow protocol=TCP localport=6000

2. 解析：

-d：表示以守护进程模式运行容器（后台运行）。
-p 5000:6000：将容器的 5000 端口映射到宿主机的 6000 端口，用于访问私有仓库。
--restart=always：设置容器在退出后自动重启，确保仓库服务始终可用。
--name registry：为容器指定名称 registry，便于后续管理。
registry：指定使用的镜像名称（即之前下载的 registry 镜像）。

3. 验证容器是否启动成功：

# 此部分功能可以使用 Podman 替代

$ docker ps

# 此部分功能可以使用 Podman 替代

$ docker ps

如果看到名为 registry 的容器正在运行，并且端口映射正确，说明启动成功。

（三）配置Docker客户端以信任私有仓库

由于私有仓库默认使用 HTTPS 协议，Docker 客户端需要配置为信任该仓库。

编辑 /etc/docker/daemon.json 文件：

$ vim /etc/docker/daemon.json

1	$ vim /etc/docker/daemon.json

添加以下内容：

{
     "insecure-registries": ["10.10.10.189:6000"]
}

{

"insecure-registries": ["10.10.10.189:6000"]

}

insecure-registries：指定不安全的仓库地址，允许 Docker 客户端通过 HTTP 协议访问该地址。

重启 Docker 服务：

$ systemctl restart docker

1	$ systemctl restart docker

重启 Docker 服务后，配置生效。

如果使用的是 Docker Desktop 则参考下图修改：

（四）上传镜像到私有仓库

此部分功能暂时不能使用 Podman 替代

1. 标记镜像：

# docker pull nginx
# docker image list
# REPOSITORY                  TAG         IMAGE ID      CREATED       SIZE
# docker.io/library/nginx     latest      4e1b6bae1e48  3 days ago    197 MB

$ docker image tag nginx:latest 10.10.10.189:6000/docker.io/library/nginx:latest

# docker pull nginx

# docker image list

# REPOSITORY TAG IMAGE ID CREATED SIZE

# docker.io/library/nginx latest 4e1b6bae1e48 3 days ago 197 MB

$ docker image tag nginx:latest 10.10.10.189:6000/docker.io/library/nginx:latest

docker image tag：用于为镜像重新标记一个新的名称和标签。
nginx:latest：本地已有的镜像名称和标签。
10.10.10.189:6000/docker.io/library/nginx:latest：目标仓库地址和镜像名称。

2. 推送镜像到私有仓库：

$ docker push 10.10.10.189:6000/docker.io/library/nginx:latest

1	$ docker push 10.10.10.189:6000/docker.io/library/nginx:latest

docker push：将标记后的镜像推送到指定的仓库地址。
如果推送成功，会显示镜像层的上传进度和最终的摘要信息。

（五）验证镜像是否上传成功

通过 API 查看仓库中的镜像：

$ curl 10.10.10.189:6000/v2/_catalog

1	$ curl 10.10.10.189:6000/v2/_catalog

三、skopeo 简化多架构同步

# macOS 15.4.2 skio 1.18.0
# brew install skopeo

# sync 同步
# --all 参数指定多架构 x86/arm/mips等
# --dest-tls-verify=false 目标地址使用 http 协议而不是 https 协议
$ skopeo sync --all --dest-tls-verify=false --src docker --dest docker docker.io/library/nginx:latest 10.10.10.189:6000/docker.io/library

# skopeo sync --all --dest-tls-verify=false --src docker --dest docker docker.io/library/tomcat:10.1-jdk21 10.10.10.189:6000/docker.io/library

# 删除镜像
# skopeo delete --tls-verify=false docker://10.10.10.189:6000/docker.io/library/nginx:latest

# 查看同步后的镜像信息
# skopeo inspect --tls-verify=false docker://10.10.10.189:6000/docker.io/library/nginx:latest

# no image found in image index for architecture "arm64", variant "v8", OS "linux"
# skopeo inspect --tls-verify=false --raw docker://10.10.10.189:6000/docker.io/library/nginx:latest | jq

# macOS 15.4.2 skio 1.18.0

# brew install skopeo

# sync 同步

# --all 参数指定多架构 x86/arm/mips等

# --dest-tls-verify=false 目标地址使用 http 协议而不是 https 协议

$ skopeo sync --all --dest-tls-verify=false --src docker --dest docker docker.io/library/nginx:latest 10.10.10.189:6000/docker.io/library

# skopeo sync --all --dest-tls-verify=false --src docker --dest docker docker.io/library/tomcat:10.1-jdk21 10.10.10.189:6000/docker.io/library

# 删除镜像

# skopeo delete --tls-verify=false docker://10.10.10.189:6000/docker.io/library/nginx:latest

# 查看同步后的镜像信息

# skopeo inspect --tls-verify=false docker://10.10.10.189:6000/docker.io/library/nginx:latest

# no image found in image index for architecture "arm64", variant "v8", OS "linux"

# skopeo inspect --tls-verify=false --raw docker://10.10.10.189:6000/docker.io/library/nginx:latest | jq

四、常见问题及解决方法

（一）无法连接到私有仓库

1. 问题描述：

在推送或拉取镜像时，可能会遇到以下错误：

Get "https://10.10.10.189:6000/v2/": dial tcp 10.10.10.189:6000: connect: connection refused

1	Get "https://10.10.10.189:6000/v2/": dial tcp 10.10.10.189:6000: connect: connection refused

2. 解决方法：

确保 /etc/docker/daemon.json 文件中正确配置了 insecure-registries。
确保 Docker 服务已重启。
确保仓库地址正确，且防火墙允许访问 6000 端口。

（二）网络问题导致无法解析地址

1. 问题描述： 如果尝试访问 http://10.10.10.189:6000 或 https://10.10.10.189:6000/v2/ 时，可能会遇到解析失败的问题。

2. 解决方法：

检查仓库地址是否正确，确保 IP 地址和端口无误。
确保网络连接正常，可以尝试 ping 或 curl 测试连通性。
如果问题仍然存在，可能是网络配置或防火墙限制，建议检查网络设置或联系网络管理员。

（三）是否可以使用 Podman 替代

目前测试 push 镜像功能是有问题的，在推送的时候会报错，其他功能都是正常的。

如下：

$ podman push 10.10.10.189:6000/docker.io/library/nginx:latest --tls-verify false
Getting image source signatures
Copying blob sha256:ccc5aac17fc4db15cf1c4562216e158143fc4540bf88a116b3862c5c205a2bbd
Copying blob sha256:9aad78ecf38071e3f8840ed045b8942764c9422f57a93f7ce3ef454cefea1493
Copying blob sha256:bd903131a05ed20c1ad9a8d5bb5b59cd0afa1b5b48683678cf71305863b74433
Copying blob sha256:9e3c6e8c1e2584acc82890d31d41f8728460629ea3933e584815122eaa954984
Copying blob sha256:8d83f6b791435d460ba4e233e9be563a2308d7712fc15239836ea01365f8c008
Copying blob sha256:ea680fbff095473bb8a6c867938d6d851e11ef0c177fce983ccc83440172bd72
Copying blob sha256:d1e3e4dd1aaaad7a94f9d28564746092e7da13a34ee69a8c23d5ae34eabdc480
Getting image source signatures
Copying blob sha256:ccc5aac17fc4db15cf1c4562216e158143fc4540bf88a116b3862c5c205a2bbd
Copying blob sha256:bd903131a05ed20c1ad9a8d5bb5b59cd0afa1b5b48683678cf71305863b74433
Copying blob sha256:ea680fbff095473bb8a6c867938d6d851e11ef0c177fce983ccc83440172bd72
Copying blob sha256:9e3c6e8c1e2584acc82890d31d41f8728460629ea3933e584815122eaa954984
Copying blob sha256:9aad78ecf38071e3f8840ed045b8942764c9422f57a93f7ce3ef454cefea1493
Copying blob sha256:8d83f6b791435d460ba4e233e9be563a2308d7712fc15239836ea01365f8c008
Copying blob sha256:d1e3e4dd1aaaad7a94f9d28564746092e7da13a34ee69a8c23d5ae34eabdc480
Getting image source signatures
Copying blob sha256:ccc5aac17fc4db15cf1c4562216e158143fc4540bf88a116b3862c5c205a2bbd
Copying blob sha256:bd903131a05ed20c1ad9a8d5bb5b59cd0afa1b5b48683678cf71305863b74433
Copying blob sha256:ea680fbff095473bb8a6c867938d6d851e11ef0c177fce983ccc83440172bd72
Copying blob sha256:8d83f6b791435d460ba4e233e9be563a2308d7712fc15239836ea01365f8c008
Copying blob sha256:9aad78ecf38071e3f8840ed045b8942764c9422f57a93f7ce3ef454cefea1493
Copying blob sha256:9e3c6e8c1e2584acc82890d31d41f8728460629ea3933e584815122eaa954984
Copying blob sha256:d1e3e4dd1aaaad7a94f9d28564746092e7da13a34ee69a8c23d5ae34eabdc480
Getting image source signatures
Copying blob sha256:ccc5aac17fc4db15cf1c4562216e158143fc4540bf88a116b3862c5c205a2bbd
Copying blob sha256:bd903131a05ed20c1ad9a8d5bb5b59cd0afa1b5b48683678cf71305863b74433
Copying blob sha256:ea680fbff095473bb8a6c867938d6d851e11ef0c177fce983ccc83440172bd72
Copying blob sha256:9e3c6e8c1e2584acc82890d31d41f8728460629ea3933e584815122eaa954984
Copying blob sha256:9aad78ecf38071e3f8840ed045b8942764c9422f57a93f7ce3ef454cefea1493
Copying blob sha256:8d83f6b791435d460ba4e233e9be563a2308d7712fc15239836ea01365f8c008
Copying blob sha256:d1e3e4dd1aaaad7a94f9d28564746092e7da13a34ee69a8c23d5ae34eabdc480
Error: trying to reuse blob sha256:ea680fbff095473bb8a6c867938d6d851e11ef0c177fce983ccc83440172bd72 at destination: pinging container registry registry-1.docker.io: Get "https://registry-1.docker.io/v2/": dial tcp 108.160.169.178:443: i/o timeout

$ podman push 10.10.10.189:6000/docker.io/library/nginx:latest --tls-verify false

Getting image source signatures

Copying blob sha256:ccc5aac17fc4db15cf1c4562216e158143fc4540bf88a116b3862c5c205a2bbd

Copying blob sha256:9aad78ecf38071e3f8840ed045b8942764c9422f57a93f7ce3ef454cefea1493

Copying blob sha256:bd903131a05ed20c1ad9a8d5bb5b59cd0afa1b5b48683678cf71305863b74433

Copying blob sha256:9e3c6e8c1e2584acc82890d31d41f8728460629ea3933e584815122eaa954984

Copying blob sha256:8d83f6b791435d460ba4e233e9be563a2308d7712fc15239836ea01365f8c008

Copying blob sha256:ea680fbff095473bb8a6c867938d6d851e11ef0c177fce983ccc83440172bd72

Copying blob sha256:d1e3e4dd1aaaad7a94f9d28564746092e7da13a34ee69a8c23d5ae34eabdc480

Getting image source signatures

Copying blob sha256:ccc5aac17fc4db15cf1c4562216e158143fc4540bf88a116b3862c5c205a2bbd

Copying blob sha256:bd903131a05ed20c1ad9a8d5bb5b59cd0afa1b5b48683678cf71305863b74433

Copying blob sha256:ea680fbff095473bb8a6c867938d6d851e11ef0c177fce983ccc83440172bd72

Copying blob sha256:9e3c6e8c1e2584acc82890d31d41f8728460629ea3933e584815122eaa954984

Copying blob sha256:9aad78ecf38071e3f8840ed045b8942764c9422f57a93f7ce3ef454cefea1493

Copying blob sha256:8d83f6b791435d460ba4e233e9be563a2308d7712fc15239836ea01365f8c008

Copying blob sha256:d1e3e4dd1aaaad7a94f9d28564746092e7da13a34ee69a8c23d5ae34eabdc480

Getting image source signatures

Copying blob sha256:ccc5aac17fc4db15cf1c4562216e158143fc4540bf88a116b3862c5c205a2bbd

Copying blob sha256:bd903131a05ed20c1ad9a8d5bb5b59cd0afa1b5b48683678cf71305863b74433

Copying blob sha256:ea680fbff095473bb8a6c867938d6d851e11ef0c177fce983ccc83440172bd72

Copying blob sha256:8d83f6b791435d460ba4e233e9be563a2308d7712fc15239836ea01365f8c008

Copying blob sha256:9aad78ecf38071e3f8840ed045b8942764c9422f57a93f7ce3ef454cefea1493

Copying blob sha256:9e3c6e8c1e2584acc82890d31d41f8728460629ea3933e584815122eaa954984

Copying blob sha256:d1e3e4dd1aaaad7a94f9d28564746092e7da13a34ee69a8c23d5ae34eabdc480

Getting image source signatures

Copying blob sha256:ccc5aac17fc4db15cf1c4562216e158143fc4540bf88a116b3862c5c205a2bbd

Copying blob sha256:bd903131a05ed20c1ad9a8d5bb5b59cd0afa1b5b48683678cf71305863b74433

Copying blob sha256:ea680fbff095473bb8a6c867938d6d851e11ef0c177fce983ccc83440172bd72

Copying blob sha256:9e3c6e8c1e2584acc82890d31d41f8728460629ea3933e584815122eaa954984

Copying blob sha256:9aad78ecf38071e3f8840ed045b8942764c9422f57a93f7ce3ef454cefea1493

Copying blob sha256:8d83f6b791435d460ba4e233e9be563a2308d7712fc15239836ea01365f8c008

Copying blob sha256:d1e3e4dd1aaaad7a94f9d28564746092e7da13a34ee69a8c23d5ae34eabdc480

Error: trying to reuse blob sha256:ea680fbff095473bb8a6c867938d6d851e11ef0c177fce983ccc83440172bd72 at destination: pinging container registry registry-1.docker.io: Get "https://registry-1.docker.io/v2/": dial tcp 108.160.169.178:443: i/o timeout

使用 docker 执行上述命令不会报错。

参考链接

更新OpenWRT系统中的所有软件包

在OpenWRT设备上，可以通过以下两种命令来更新系统所有软件包：

仅更新LuCI相关的软件包（Web管理界面）：

$ opkg list-upgradable | grep luci- | cut -f 1 -d ' ' | xargs opkg upgrade --force-overwrite

1	$ opkg list-upgradable \| grep luci- \| cut -f 1 -d ' ' \| xargs opkg upgrade --force-overwrite

更新所有可升级的软件包（包括系统内核和其他组件）：

$ opkg list-upgradable | cut -f 1 -d ' ' | xargs opkg upgrade --force-overwrite

1	$ opkg list-upgradable \| cut -f 1 -d ' ' \| xargs opkg upgrade --force-overwrite

为什么要更新OpenWRT软件包？

保持OpenWRT系统及其软件包的最新版本，不仅能让系统享有最新的功能和性能优化，还能显著提高设备的安全性。每一次更新，通常都包含以下内容：

安全补丁：随着时间的推移，可能会发现系统中的安全漏洞。更新能够及时修复这些漏洞，避免设备受到攻击。
功能改进：新的软件包版本往往带来新功能，或改进现有功能，让系统更加易用和强大。
性能优化：定期更新不仅能修复Bug，还能提升系统的性能，使网络设备运行更加流畅。
兼容性和稳定性：更新可能包含对硬件和软件兼容性的提升，减少运行中出现的问题，保持系统的长期稳定性。

更新命令的使用方法：

本文将从最基本的更新软件包源开始，接着详细介绍两种可供选择的升级方式——只更新LuCI相关组件或更新所有软件包。用户可以根据需求选择相应的命令。

第一步：更新软件包源

无论你打算只更新LuCI相关的组件，还是更新整个系统，首先都需要刷新软件包源列表。这一步可以确保系统从最新的软件包存储库中获取信息，并知道哪些软件包有更新可用。

$ opkg update

1	$ opkg update

详细解释：

opkg update：这个命令不会直接升级软件包，而是更新系统的软件包源列表。它会连接到OpenWRT的软件包存储库，获取最新的包信息，包括版本号、依赖关系等。执行完这个命令后，设备将知道哪些软件包可以升级，从而为后续的升级操作做好准备。

选择1：仅更新LuCI相关的软件包

如果你只想更新LuCI Web管理界面和相关插件，而不想影响其他系统组件，可以使用以下命令：

$ opkg list-upgradable | grep luci- | cut -f 1 -d ' ' | xargs opkg upgrade --force-overwrite

1	$ opkg list-upgradable \| grep luci- \| cut -f 1 -d ' ' \| xargs opkg upgrade --force-overwrite

详细解释：

opkg list-upgradable：列出当前系统中所有可以升级的软件包及其版本信息。输出内容通常会包括包名、当前安装版本和最新可用版本。

例如：

luci-app-firewall - 1.1-1 - 1.2-1 luci-base - 1.1-1 - 1.2-1

1
2
3

luci-app-firewall - 1.1-1 - 1.2-1

luci-base - 1.1-1 - 1.2-1

这表示 luci-app-firewall 和 luci-base 都有新版本可以升级。
grep luci-：筛选出所有以 “luci-” 开头的软件包。LuCI相关的所有软件包名称通常都以“luci-”开头，如 luci-base、luci-app-firewall 等。因此，这个命令确保只筛选和更新LuCI相关的软件包。
cut -f 1 -d ' '：将筛选结果中的包名提取出来，忽略版本信息。输出的内容会类似于：

luci-app-firewall luci-base

1
2
3

luci-app-firewall

luci-base
xargs opkg upgrade：xargs 是用于将前面筛选出的包名传递给 opkg upgrade 命令的工具。它将每个包名作为参数传递给 opkg upgrade，然后逐个升级这些包。

使用场景：

如果你只关心Web界面和相关管理功能的升级，而其他系统组件都不需要更改，可以选择这种方法。这可以减少升级的范围，降低更新过程中出现问题的风险。

选择2：更新所有可升级的软件包

如果你希望更新系统中所有的软件包，包括内核、应用程序、以及网络相关工具，可以使用以下命令：

$ opkg list-upgradable | cut -f 1 -d ' ' | xargs opkg upgrade --force-overwrite

1

$ opkg list-upgradable | cut -f 1 -d ' ' | xargs opkg upgrade --force-overwrite

详细解释：
- opkg list-upgradable：与前面一样，用于列出所有可以升级的软件包。它会显示每个软件包的名称及其版本更新信息。
- cut -f 1 -d ' '：这条命令将所有软件包名称提取出来，去掉版本信息。和前面的命令类似，它将结果简化为只有包名。
- xargs opkg upgrade：这一步是将所有提取出的包名传递给 opkg upgrade 命令，然后逐一升级这些包。这是一次性更新系统中所有软件包的命令，确保系统中的每一个组件都保持最新。
使用场景：

当你希望确保系统中的所有软件包都保持最新，或者希望全面更新系统时，这条命令非常适合。它不仅会更新LuCI，还会更新内核和所有安装的应用程序、驱动程序等。

更新所有软件包的风险与注意事项

在执行更新前，请注意以下几点：
内核更新的风险：更新所有软件包时，可能会涉及内核更新。内核更新可能会提升性能或修复安全问题，但同时也可能导致设备重启，或某些依赖于旧内核的功能失效。如果你使用了第三方驱动或定制的内核模块，更新内核可能会导致系统不稳定。
存储空间不足：OpenWRT设备的存储和内存往往有限，更新大量软件包时，可能会耗尽可用的存储空间。请务必提前检查设备的存储空间，以避免更新过程中出现失败，或导致系统崩溃。可以使用以下命令检查剩余存储空间：

$ df -h

1

$ df -h
备份系统配置：在执行大规模更新之前，务必备份你的系统配置文件。这可以通过LuCI Web界面或者命令行来完成。如果更新过程中出现问题，备份将是恢复系统的关键。
逐步更新的建议：如果设备正在正常运行，建议分阶段进行更新。例如，可以先更新LuCI Web界面，观察系统的稳定性，再逐步更新其他软件包，避免一次性大规模更新可能导致的系统问题。

备份与恢复

为了确保在更新过程中万一出现问题时能够快速恢复系统，建议在更新前进行配置备份。可以使用以下两种方式备份：

通过LuCI界面：登录LuCI Web管理界面，导航到“系统 > 备份/升级”页面，点击“生成备份”按钮，下载配置文件到本地。
通过命令行备份：

$ sysupgrade -b /tmp/backup.tar.gz

1

$ sysupgrade -b /tmp/backup.tar.gz

然后可以通过SCP或FTP下载该备份文件到本地电脑。

总结

通过上述命令，OpenWRT用户可以轻松更新系统中的所有软件包。你可以选择仅更新LuCI Web界面，或者全面升级所有系统组件（包括内核）。在执行更新前，务必确保做好配置备份并确认设备有足够的存储空间，这将帮助你保持系统的安全性、功能完备性以及长期稳定性。

参考链接

更新OpenWRT系统中的所有软件包

米家石墨烯智能电暖器电源开关维修

天气渐凉，翻出以前购买的小米 “米家石墨烯智能电暖器”，如下图：

通电测试功能，结果发现开关只能处于导通状态，无法关闭。关机需要直接拔掉插头，安全性没有保障。以前曾经闻到过烧糊的气味，但是功能正常，于是就没有太在意。

今天拆开发现开关的 1号管脚 烧糊了，如下图：

开关烧糊的另一面，如下图：

出问题的原因是 1号管脚 的接头没有卡紧，导致虚接发热，开关过热损坏，绝缘热缩管也都烤糊了，部分导线需要更换。

这部分的问题还是蛮严重的，可能诱发着火问题。小米的品控持续堪忧。

解决方法比较简单，更换一个新的开关模块，并且需要清理烧糊的插头，重新压线。不要复用原来的插头，原来的插头已经受热氧化，即使勉强能用也会由于电阻升高，依旧诱发接头过热。

开关的原始安装位置，开关的灯是向上的，后面安装的时候参考下图即可：

淘宝搜索 “HS9 智米小米取暖器二挡电源开关艾美特电暖器开关大电流船型开关”/ “智米小米1S取暖器开关”/“HUACONN 3脚2挡”，可以找到替代开关。参考商家链接东莞蓝浩电子。

至于已经烧的发黑的连接线，可以在淘宝搜索 “6.3 双头高温编织线” ，线号选择 1.5平编织线，购买合适颜色的，我这边是白色的，原来的线接头是旗形的，其实内部安装空间足够，非旗型也是可以的。参考商家链接东莞市悦泰电子。

其他符合如下尺寸的开关也可以进行替换安装：

注意，拆螺丝的时候，有一颗三角形的特殊螺丝，可以使用 2.3MM 的螺丝刀/批头拆卸。恰好家里以前买过一套 “米家精修螺丝刀套装” ，里面的三角批头刚刚合适。

套装如下图：

没有这个套装的话，可以淘宝搜索 “2.3mm三角螺丝刀”，购买一把即可。

chrome浏览器如何跟踪新开标签的网络请求？

调试前端页面的时候，有时候会遇到点击弹窗后从另外一个标签页打开页面的情况，这个时候如果手工去打开调试工具，页面加载之前的网络接口调用就追踪不到了，这个问题查询了一下，从 Chrome 50 版本开始支持页面跳转调试器自动跟踪。只是默认情况下，此功能没有开启，需要手工开启此功能。

具体开启此功能的操作如下：

1. 打开浏览器控制台(F12)/开发者工具

2.使用三点菜单(F1，控制台右上角X号旁边的那个按钮打开 setting 栏)

继续阅读chrome浏览器如何跟踪新开标签的网络请求？

2025 年 10 月
一	二	三	四	五	六	日
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31

参考链接

参考链接

前置条件

问题现象

问题定位

概要

Introduction

Why Use Multistage Builds?

The Challenge: Sharing Variables Across Stages

Introducing ARG: The Basics

Sharing ARG Variables Across Stages

Advanced Usage: Combining ARG with Environment Variables

Key Points on Environment Variables in Multistage Builds

Debugging ARG Variables

Best Practices for Using ARG

Conclusion

参考链接

一、概述

二、搭建步骤

（一）下载Docker Registry镜像

（二）启动Docker Registry容器

（三）配置Docker客户端以信任私有仓库

（四）上传镜像到私有仓库

（五）验证镜像是否上传成功

三、skopeo 简化多架构同步

四、常见问题及解决方法

（一）无法连接到私有仓库

（二）网络问题导致无法解析地址

（三）是否可以使用 Podman 替代

参考链接

为什么要更新OpenWRT软件包？

更新命令的使用方法：

第一步：更新软件包源

选择1：仅更新LuCI相关的软件包

选择2：更新所有可升级的软件包

更新所有软件包的风险与注意事项

备份与恢复

总结

参考链接