4.2MB 的域名重定向服务

手头囤了一堆闲置域名，想做跳转服务却被 Caddy 的配置文件搞得头疼？这个 4.2MB 的 Go 服务可能正是你需要的解决方案。

domain-redirect 是一个专门解决域名重定向需求的轻量级服务。它的核心价值在于将复杂的配置简化为几行环境变量，同时保持足够的灵活性来应对真实的生产环境需求。

项目地址： https://github.com/nexmoe/domain-redirect

三分钟上手

最简单的部署方式是使用 Docker：

docker run -d \
  -p 8080:8080 \
  -e DOMAIN_MAPPING_1=example.com->https://target1.com,https://target2.com \
  nexmoe/domain-redirect

这条命令会启动一个重定向服务，将访问example.com的请求轮询转发到两个目标地址。

如果需要更复杂的配置，创建一个docker-compose.yml文件：

version: '3'
services:
  domain-redirect:
    image: nexmoe/domain-redirect
    ports:
      - "8080:8080"
    environment:
      - DOMAIN_MAPPING_1=blog.example.com->https://blog.target.com
      - DOMAIN_MAPPING_2=shop.example.com->https://shop1.com,https://shop2.com
      - PRESERVE_PATH=true
      - INCLUDE_REFERRAL=true
    restart: unless-stopped

现在，所有域名都会按配置规则进行重定向，路径会被保留，同时会添加来源信息用于统计分析。

完整配置说明

域名映射配置

服务通过环境变量进行配置，每个域名映射规则使用 DOMAIN_MAPPING_* 格式：

DOMAIN_MAPPING_<任意名称>=<域名>-><目标地址1>,<目标地址2>,...

例如：

DOMAIN_MAPPING_1=example.com->https://target1.com,https://target2.com
DOMAIN_MAPPING_BLOG=blog.example.com->https://myblog.com
DOMAIN_MAPPING_SHOP=shop.example.com->https://shop1.com,https://shop2.com,https://shop3.com

功能配置参数

• PORT: 服务监听端口，默认为 8080
• PRESERVE_PATH: 是否保持原始路径，默认为 false。设置为 “true” 时，重定向会保留原始请求路径
• INCLUDE_REFERRAL: 是否携带来源域名信息，默认为 false。设置为 “true” 时，重定向会添加 ref 参数
• ENABLE_TIMESTAMP: 是否启用时间戳参数，默认为 false。设置为 “true” 时，重定向会添加 _t 参数防止缓存

使用示例

假设配置了完整的参数：

DOMAIN_MAPPING_1=example.com->https://target1.com,https://target2.com
PRESERVE_PATH=true
INCLUDE_REFERRAL=true
ENABLE_TIMESTAMP=true

当访问 http://example.com/api/users 时，可能会重定向到：

https://target1.com/api/users?ref=example.com&_t=1672531200

轻量化

4.2MB 的镜像大小和 1.277MB 的内存占用数字看似平常，但背后体现的是对资源效率的极致追求。在云原生时代，这种轻量化设计带来的不仅是成本优势，更是部署和扩展的便利性。

传统的 Web 服务器如 Nginx 或 Apache 动辄几十 MB 的镜像大小，对于单纯的重定向需求显得过于「重装上阵」。而 domain-redirect 选择 Go 语言开发，正是看中了 Go 在编译后二进制文件体积小、运行时开销低的特性。

更重要的是环境变量配置方式的选择。相比配置文件，环境变量在容器化部署中具备天然优势：

• 容器编排平台（如 Kubernetes）对环境变量有原生支持
• 配置变更无需重构镜像，只需重启容器
• 敏感信息可以通过 Secret 管理，避免明文存储

多目标轮询的实际应用场景

多目标轮询不仅是负载均衡的简化版本，在特定场景下有其独特价值。

以内容分发为例，假设你有一个域名指向多个 CDN 节点，通过轮询可以在某个节点出现问题时自动切换到备用节点。这比专业的负载均衡器更适合小规模或实验性项目。

另一个场景是 A/B 测试。通过配置不同的目标地址，可以将用户流量按比例分配到不同版本的应用，观察用户行为差异。当然，这种方式相比专业的 A/B 测试平台功能有限，但对于简单的对比测试已经足够。

来源追踪与数据分析

INCLUDE_REFERRAL参数。当启用此功能时，重定向 URL 会自动添加ref参数，值为来源域名。

这个看似简单的功能解决了跳转服务的一个关键痛点：流量来源追踪。传统的 HTTP Referer 头在某些情况下会被浏览器过滤或修改，而 URL 参数则更加可靠。

配合 Google Analytics 等统计工具，你可以精确知道哪些域名为目标站点带来了流量，进而评估不同域名的价值。这对于拥有多个域名的站长来说是极其实用的功能。

KISS (Keep It Simple, Stupid)

从技术架构角度看，domain-redirect 的设计不试图成为全能的反向代理，而是专注于重定向这一核心功能。

Go 语言的选择也值得思考。相比 Node.js 或 Python，Go 的编译型特性确保了部署的一致性——你不需要担心目标环境的运行时版本问题。同时，Go 的并发模型天然适合处理大量的 HTTP 重定向请求。

服务的状态管理也很巧妙。轮询状态保存在内存中，重启后会重置到第一个目标。这种设计虽然牺牲了状态持久化，但极大简化了架构复杂度，对于重定向服务来说是合理的权衡。