docs: add docs for network.rules - #115

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "Repo files around target:"
fd -a '07\.出网请求头转换\.md' . || true class="pl-s">"$(fd '07\.出网请求头转换\.md' . | head -n 1 || true)"
if [ -n "$target" ]; then
  echo "Target: $target"
  wc -l "$target"
  echo "Lines 280-310:"
  sed -n '280,310p' "$target" | cat -n -v
  echo "Occurrences of date/version terms:"
  rg -n "v0\.0\.44|2026-08-15|平台 CA|template|CA|自定义镜像|官方镜像" "$target"
fi

echo "Search repository for v0.0.44 / 2026-08-15 / 模板 CA:"
rg -n "v0\.0\.44|2026-08-15|平台 CA|自定义镜像|官方镜像" docs .github 2>/dev/null || true

Repository: aliyun-fc/fc-docs

Length of output: 46895

🌐 Web query:

阿里云函数计算 e2b runtime base v0.0.44 fc-e2b-registry cr.aliyuncs.com CA 模板 CA 2026

💡 Result:

在阿里云函数计算（Function Compute, FC）的云沙箱（E2B）服务中，fc-e2b-registry 是官方维护的镜像仓库域名，用于存储各类预置的沙箱环境镜像 [1][2][3]。 关于你提到的版本和资源： 1. 关于 v0.0.44 镜像： fc-e2b-registry.cn-beijing.cr.aliyuncs.com/runtime/code-interpreter-v1:v0.0.44 等镜像版本确实存在，并被用于构建 E2B 兼容的沙箱模板 [4]。官方文档建议在构建自定义镜像模板时，直接使用这些预置的官方镜像，无需您额外提供 ACR EE 实例 [1][2]。 2. 关于 Base 模板： base 模板是云沙箱提供的一种最小化运行环境，仅包含 E2B envd 兼容的基础服务（支持沙箱生命周期管理、基础 Shell 命令执行和文件系统访问），不预置代码解释器或浏览器自动化服务 [5][3]。它常作为自定义业务运行时或工具链的基础基线 [5]。 3. 使用方式（示例）： 在使用 E2B SDK 时，你可以指定 FROM_IMAGE 来构建自定义模板。以下是基于官方推荐的构建方式： E2B_API_KEY=e2b_xxx FROM_IMAGE="fc-e2b-registry.cn-beijing.cr.aliyuncs.com/runtime/code-interpreter-v1:v0.0.44" # 使用 Python SDK 构建模板 from e2b import Template, default_build_logger import os build = Template.build( Template.from_image(os.environ["FROM_IMAGE"]), name="my-custom-template", cpu_count=2, memory_mb=2048, on_build_logs=default_build_logger,) 如果你的需求是使用标准的 Python 代码解释能力，通常推荐直接使用 code-interpreter-v1 模板；如果需要高度定制环境（如安装特定的系统库），则基于 base 或 code-interpreter-v1 镜像进行扩展 [5][3]。这些信息在 2026 年 8 月的阿里云官方文档中是有效的 [5][3]。

Citations:

• 1: https://www.alibabacloud.com/help/zh/functioncompute/build-a-custom-image-template
• 2: https://help.aliyun.com/zh/functioncompute/build-a-custom-image-template
• 3: https://www.alibabacloud.com/help/zh/functioncompute/built-in-templates/
• 4: https://help.aliyun.com/zh/functioncompute/overview-of-templates
• 5: https://www.alibabacloud.com/help/zh/functioncompute/base-template

🌐 Web query:

site:docs.aliyun.com 函数计算 e2b 出网请求头转换 自定义镜像 模板 CA

💡 Result:

相关阿里云文档主要是：

1. 构建自定义镜像模板：介绍 E2B 模板、自定义镜像、镜像转换模式、请求头配置、ACR EE/VPC、CA 证书等。重点搜索词中的“自定义镜像、模板、CA、请求头转换”都在此文档中。[1]

2. 定义模板：介绍通过 E2B SDK 的 Template.build() 和 Template.from_image() 从镜像创建模板。[2]

3. 基础镜像：说明模板构建使用的基础镜像格式及 ACR EE 镜像要求。[3]

其中与“请求头转换”最相关的配置包括：

headers = {
    "X-E2B-Template-Build-Mode": "builder",  # 或 direct
    "X-E2B-Template-Source-Registry-Type": "acree",
    "X-E2B-Template-Dest-Image-Ref": "...",
    "X-E2B-Template-Alpha-RegistryConfig-CertConfig-Insecure": "false",
}

builder 会将普通业务镜像转换为云沙箱模板镜像；direct 则要求源镜像本身已包含 E2B 运行依赖。[1]

Sources:

[1] (help.aliyun.com)
[2] (help.aliyun.com)
[3] (help.aliyun.com)

Citations:

• 1: https://help.aliyun.com/zh/functioncompute/build-a-custom-image-template?utm_source=openai
• 2: https://help.aliyun.com/zh/functioncompute/define-template?utm_source=openai
• 3: https://help.aliyun.com/zh/functioncompute/base-image?utm_source=openai

🌐 Web query:

site:help.aliyun.com "平台 CA" "v0.0.44" "2026-08-15" "出网请求头转换"

💡 Result:

经查证，截至2026年8月10日，阿里云及其相关生态产品中并没有名为“平台 CA v0.0.44”且在2026年8月15日发布“出网请求头转换”功能的记录。 您的查询可能涉及以下技术概念的混淆或特定企业内部系统的版本更新： 1. 技术背景：在阿里云产品体系中，“出网请求头转换”（或称“回源HTTP请求头修改”）是边缘安全加速（ESA）、CDN、DCDN以及API网关等产品的标准功能 [1][2][3][4][5]。这些功能通常用于在请求回源时添加、修改、删除或重写HTTP请求头，以满足业务对接需求 [1][2][3]。 2. 版本记录参考： - 阿里云 Lingma 系列（Qoder CN CLI）在2026年7月13日曾发布 v1.0.44 版本 [6]。 - Cloud Agents CN 的版本号序列中包含 0.5.0 等版本，但并未检索到与“CA v0.0.44”完全吻合的发布记录 [7]。 如果这是您所在公司或特定内部平台的发布需求，建议直接查阅该平台的官方发布说明文档（Release Notes）或联系内部技术支持团队以获取准确的更新日志。如果您确认该信息属于阿里云产品，建议提供更准确的产品名称以供进一步核实。

Citations:

• 1: https://help.aliyun.com/zh/edge-security-acceleration/esa/user-guide/modify-outgoing-request-header
• 2: https://help.aliyun.com/zh/edge-security-acceleration/esa/user-guide/conversion-rules-overview/
• 3: https://help.aliyun.com/zh/api-gateway/traditional-api-gateway/user-guide/transformer-plug-in
• 4: https://help.aliyun.com/zh/edge-security-acceleration/dcdn/configure-custom-request-headers
• 5: https://help.aliyun.com/zh/cdn/user-guide/configure-custom-request-headers
• 6: https://help.aliyun.com/zh/lingma/qoder-cn-cli
• 7: https://help.aliyun.com/zh/lingma/product-overview/cloud-agents-cn-update-log

🏁 Script executed:

#!/bin/bash
set -euo pipefail

rg -n -C 3 \
  'update_network|Python SDK|2\.11|Python 3\.10|Python 3\.9|PUT /sandboxes/\{id\}/network' \
  docs/zh-CN/01.云沙箱/04.功能说明/06.网络/05.网络访问控制.md \
  docs/zh-CN/01.云沙箱/04.功能说明/06.网络/07.出网请求头转换.md || true

Repository: aliyun-fc/fc-docs

Length of output: 5338

🏁 Script executed:

#!/bin/bash
set -euo pipefail

python3 - <<'PY'
from pathlib import Path
import re

src = Path("docs/zh-CN/01.云沙箱/04.功能说明/06.网络/07.出网请求头转换.md").read_text(encoding="utf-8")
near = "\n".join(src.splitlines()[160:168])
sections = {
    "runtime": re.search(r"^## 运行时更新.*?(?=^## )", src, flags=re.M | re.S),
    "create": re.search(r"^## 创建沙箱与设置网络.*?(?=^## )", src, flags=re.M | re.S),
}
terms = {
    "has_update_network_mention": "update_network" in near,
    "has_update_network_code": bool(re.search(r"update_network\(", src)),
    "python_sdk_version_in_near": bool(re.search(r"Python SDK[^\\d]*(\d+\.?)*|SDK[^\\d]*(\d+\.?)*|2\.11|3\.10|3\.9", near)),
    "python_runtime_version_in_near": bool(re.search(r"Python[^\\d]*(\d+\.?\d*)?|3\.10|3\.9", near)),
}
print("near_runtime_heading:")
print(near.rstrip("\n"))
print("\nsection_coverage:")
for k, m in sections.items():
    print(f"{k}: {bool(m)}")
print("\nterms:", terms)
PY

Repository: aliyun-fc/fc-docs

Length of output: 799

🏁 Script executed:

#!/bin/bash
set -euo pipefail

files="$(fd -a -I -t f 'package\.json|\.nvmrc|\.node-version|Dockerfile|\.tool-versions' . || true)"
if [ -n "$files" ]; then
  printf '%s\n' "$files" | xargs -r rg -n \
    'engines|node-version|FROM node|NODE_EXTRA_CA_CERTS|use-system-ca'
fi

Repository: aliyun-fc/fc-docs

Length of output: 159

🌐 Web query:

Node.js --use-system-ca NODE_EXTRA_CA_CERTS CLI documentation nodejs.org

💡 Result:

In Node.js, --use-system-ca and NODE_EXTRA_CA_CERTS are mechanisms used to manage and extend the trusted Certificate Authority (CA) certificates used for TLS validation [1]. --use-system-ca The --use-system-ca flag (or the NODE_USE_SYSTEM_CA=1 environment variable) instructs Node.js to load CA certificates from the operating system's trust store [1]. When enabled, Node.js uses these system CAs in addition to its bundled CAs (a snapshot of the Mozilla CA store) [1]. On Windows and macOS, Node.js follows platform-specific policies for locally trusted certificates [2]. On other platforms (such as Linux), Node.js typically loads certificates from the default files and directories respected by the linked OpenSSL library (e.g., /etc/ssl/cert.pem and /etc/ssl/certs) [2]. NODE_EXTRA_CA_CERTS The NODE_EXTRA_CA_CERTS environment variable allows you to extend the set of trusted CAs by specifying a file containing one or more additional certificates in PEM format [3]. When set, Node.js reads this file only at process launch [3]. This variable is ignored if the process is running with elevated privileges (setuid root or with Linux file capabilities) [3]. It is also ignored if the ca option is explicitly specified in a TLS or HTTPS request [3]. Combining Options These mechanisms can be used together [1]. When both --use-system-ca and NODE_EXTRA_CA_CERTS are configured, Node.js trusts the bundled CA store, the system CA store, and the additional certificates provided via the environment variable [1]. Note: These settings do not apply when the ca property is explicitly configured for an individual tls.connect or https.request method [1][3].

Citations:

• 1: https://nodejs.org/learn/http/enterprise-network-configuration
• 2: nodejs/node@44b19ec534
• 3: https://nodejs.org/docs/latest-v19.x/api/cli.html

🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf 'Target file lines 260-300:\n'
sed -n '260,300p' 'docs/zh-CN/01.云沙箱/04.功能说明/06.网络/07.出网请求头转换.md' | cat -n

printf '\nRepository search for e2b-ca.crt and CA trust wording:\n'
rg -n "e2b-ca\.crt|Node\.js|nodejs|ca-certificates|truststore|NODE_EXTRA_CA_CERTS|--use-system-ca|系统 CA|内置 CA|平台 CA" .

Repository: aliyun-fc/fc-docs

Length of output: 50373

🌐 Web query:

Node.js ca certificates Linux OpenSSL CApath default NODE_EXTRA_CA_CERTS --use-system-ca

💡 Result:

In Node.js, the handling of CA certificates on Linux is primarily managed through the following mechanisms, which allow you to extend or replace the default set of trusted authorities [1][2]. 1. --use-system-ca (Flag or NODE_USE_SYSTEM_CA) The --use-system-ca flag (or the NODE_USE_SYSTEM_CA environment variable) instructs Node.js to load CA certificates from the default OpenSSL certificate file and directory [3][4]. When enabled, Node.js uses the paths typically configured for the version of OpenSSL it is linked against—usually /etc/ssl/cert.pem for the default file and /etc/ssl/certs for the default directory [3]. These certificates are cached upon the first load [5][3]. This flag is intended to help developers securely include system-wide trusted CAs, especially when encountering common certificate verification errors [6]. 2. NODE_EXTRA_CA_CERTS The NODE_EXTRA_CA_CERTS environment variable allows you to extend the set of well-known, bundled CA certificates with additional certificates in PEM format [7]. When this variable is set to a path pointing to a file containing one or more trusted certificates, those certificates are added to the trusted store [7][8]. - Usage: This variable is read only once during the startup of the Node.js process; changing it at runtime (e.g., via process.env) has no effect [7][9]. - Limitations: It is ignored if the Node.js process runs as setuid root or has Linux file capabilities set [7]. It is also not used if the ca option is explicitly provided to a TLS/HTTPS client or server [7]. 3. Default Behavior By default, if neither --use-system-ca nor NODE_EXTRA_CA_CERTS is configured, Node.js relies on a bundled set of CA certificates [1][2]. The --use-system-ca flag and --use-openssl-ca are mutually exclusive [1]. If you need both custom certificates and system-wide certificates, you can combine --use-system-ca with NODE_EXTRA_CA_CERTS [4]. 4. OpenSSL Environment Variables Node.js respects standard OpenSSL environment variables such as SSL_CERT_FILE and SSL_CERT_DIR [3][2]. If these are set, they can override the default paths Node.js uses when --use-system-ca is enabled [3]. These variables can be used as a workaround if the standard paths on your Linux distribution differ from those expected by the linked OpenSSL library [3].

Citations:

• 1: https://github.com/nodejs/node/blob/d90d9d55/src/crypto/crypto_context.cc
• 2: nodejs/node@33012e9
• 3: nodejs/node@44b19ec534
• 4: https://nodejs.org/learn/http/enterprise-network-configuration
• 5: crypto: support --use-system-ca on non-Windows and non-macOS nodejs/node#57009
• 6: https://nodejs.org/api/tls.html
• 7: https://nodejs.org/docs/latest-v19.x/api/cli.html
• 8: crypto: allow adding extra certs to well-known CAs nodejs/node#9139
• 9: https://r2.nodejs.org/docs/v18.11.0/api/cli.html