AyuCLouD-Services返回首页

transmission docker 部署与网络排查：Compose、DNS、MTU 和端口

更新于 2026-10-18 · ayu-ssr.buzz

简答：transmission docker 通常是指在 Docker 容器中运行 Transmission。本文以 LinuxServer.io 的公开镜像示例说明 Compose 部署，并重点排查容器网络、DNS、MTU、端口映射、丢包和多层 NAT；该镜像不等同于 Transmission 官方发行方式，具体参数应以当前维护文档和 Transmission 官方文档为准。

定义：Transmission Docker 是把 Transmission 服务放进 Docker 容器运行，并通过挂载目录保存配置和下载数据、通过端口映射提供 Web 管理与节点连接。

先明确 transmission docker 的适用范围与风险

本站不是 Transmission 项目官网，也与相关镜像维护者不存在授权关系。本文是第三方部署与网络排查整理，镜像版本、参数和界面可能发生变化；认证、端口、配置文件和服务状态应以对应官方或维护者文档为准。Transmission 属于通用 BitTorrent 客户端，请仅用于有权获取、分发或备份的内容，并遵守所在地法律、版权许可和网络服务条款。

搜索 transmission docker 的用户，通常有两类需求：一是用 Docker Compose 快速运行 Transmission，二是容器已经启动，但遇到 Web 页面打不开、DNS 解析失败、连接超时、端口关闭、延迟高或丢包。Docker 只能解决程序隔离和部署管理，不能自动解决宿主机防火墙、路由器端口转发、上游 NAT、MTU 或线路质量问题。

本文资料核对日期为 2026-10-18。部署示例参考 LinuxServer.io 当前公开的 Transmission 镜像说明；该页面列出 /config、/downloads、/watch 等挂载路径，以及 9091、51413 TCP 和 51413 UDP 的示例映射。参考：LinuxServer.io Transmission 镜像说明。

用 Docker Compose 创建可复现的基础部署

开始前准备已安装 Docker Engine 和 Docker Compose 的 Linux 主机，并准备配置目录、下载目录和可选的监视目录。不要直接照抄示例中的 UID、GID、密码和宿主机路径；应按自己的用户、目录和访问范围修改。

创建工作目录：

mkdir -p ~/transmission-docker
cd ~/transmission-docker
sudo mkdir -p /srv/transmission/config /srv/transmission/downloads /srv/transmission/watch

可用下面的 Compose 配置作为起点。这里用 HTML 空格保留 YAML 层级，复制后仍应检查缩进；如果编辑器支持，建议将内容保存为 compose.yml 后执行格式校验。

services:
  transmission:
    image: lscr.io/linuxserver/transmission:latest
    container_name: transmission
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - USER=change-this-user
      - PASS=change-this-password
      - PEERPORT=51413
    volumes:
      - /srv/transmission/config:/config
      - /srv/transmission/downloads:/downloads
      - /srv/transmission/watch:/watch
    ports:
      - 9091:9091
      - 51413:51413
      - 51413:51413/udp
    restart: unless-stopped

重要：PUID 和 PGID 应使用实际运行目录所属用户的 UID 与 GID。可以运行 id 用户名 查询，不要默认认为所有主机都使用 1000。USER 和 PASS 用于 Web 界面认证，示例凭据必须替换；不要把未认证的管理端口直接暴露到公网。

LinuxServer.io 文档说明，PEERPORT 应与 Docker 配置中映射的 Transmission 连接端口保持一致；它还明确列出 9091 为 Web UI、51413 TCP 和 UDP 为 Torrent 端口。参考：镜像参数与端口说明。

启动和查看日志：

docker compose config
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=100 transmission

如果需要从同一台主机访问，可先测试 http://127.0.0.1:9091；如果从其他设备访问，则使用宿主机地址和实际映射的宿主机端口。Transmission 官方 Web 界面文档也将 9091 列为默认远程控制端口。参考：Transmission Web 界面文档。

目录、端口与网络层分别怎么理解

项目容器内位置或端口作用优先排查项
配置/config保存配置、日志和任务状态宿主机目录是否存在、是否可写
下载/downloads保存未完成和已完成文件容器路径是否写对、UID/GID 是否匹配
监视目录/watch可选的种子文件监视目录挂载是否存在、当前镜像是否支持所需行为
Web/RPC9091访问 Web 管理界面和 RPC端口监听、防火墙、认证和访问范围
peer port51413 示例节点连接使用的 TCP/UDP 端口PEERPORT、Compose 映射、路由器和上游 NAT

宿主机路径和容器路径不能混用。例如 Compose 将 /srv/transmission/downloads 挂载到容器内的 /downloads 后，Transmission 的下载目录应填写 /downloads。如果填写宿主机路径，应用可能找不到目录或无法写入。

9091 与 peer port 不是同一个问题。9091 主要用于管理界面和 RPC；peer port 用于节点连接。Web 页面能打开，只能证明管理端口路径基本可达，不代表节点连接、端口转发或外部网络质量正常。

Transmission 官方端口转发指南指出，要让其他节点连接到实例，需要在防火墙和路由器上放行或转发对应端口；Docker 的端口映射只完成容器与宿主机之间的一层转发，不能替代路由器配置。参考：Transmission 官方端口转发指南。

容器网络排查：先区分 DNS、MTU、端口和丢包

遇到“容器启动了但任务没有连接”时，建议按以下顺序排查，不要一开始就更换镜像或反复重启：

  1. 确认容器状态：运行 docker compose ps 和 docker compose logs --tail=200 transmission，先排除容器反复退出、配置错误或权限错误。
  2. 确认 Web 端口：在宿主机执行 curl http://127.0.0.1:9091。若本机可访问而其他设备不能访问，重点检查宿主机防火墙、云安全组、访问地址和端口绑定范围。
  3. 确认容器出站：使用 docker exec -it transmission sh 进入容器，再根据镜像内可用工具测试域名解析和 HTTPS 出站。若没有 ping、nslookup 或 curl，不要据此判断网络一定失败，应结合宿主机和日志验证。
  4. 确认 DNS：Compose 支持通过 dns 为容器网络接口指定 DNS 服务器，也支持 dns_opt 设置解析选项。不要在没有解析失败证据时随意替换 DNS。参考：Docker Compose services 文档。
  5. 确认 MTU：如果出现部分站点能访问、HTTPS 握手卡住、连接间歇性超时或经过隧道后丢包，可检查宿主机网卡、Docker 网桥和上游链路的 MTU。Docker 官方文档说明，用户自定义 bridge 网络可以通过 com.docker.network.driver.mtu 设置容器网络 MTU，但不应在没有路径测试和对照结果时盲目修改。
  6. 确认端口与 NAT：检查 PEERPORT 是否和 TCP/UDP 映射一致，再判断宿主机防火墙、路由器、多层 NAT 或上游网络是否阻止入站连接。端口关闭不等于 Docker 部署失败。
  7. 确认丢包与延迟：分别测试宿主机到网关、宿主机到目标地址、容器到目标地址。若只有容器异常，重点看 Docker 网络、DNS 或 MTU；若宿主机和容器都异常，优先检查线路、路由和上游网络。

Docker 官方文档说明，默认 Compose 网络通常是 bridge 网络；容器通过 NAT 获得外部网络访问，发布端口则把宿主机端口转发到容器端口。自定义 bridge 网络还可以提供容器间名称解析和独立网络参数。参考：Docker bridge 网络文档。

Docker 网络模式、DNS 与 MTU 的选择原则

一般单容器部署不需要 network_mode: host。默认的 Compose bridge 网络配合明确的 ports 映射，更容易区分管理端口、peer port 和宿主机防火墙。Docker Compose 文档说明，使用 host 模式时容器共享宿主机网络栈，通常不再需要端口映射；这会改变隔离和排查方式，因此只有在确有需求时使用。参考：Docker Compose 网络文档。

如果容器内域名解析失败，可以临时在 Compose 服务中加入明确的 dns 配置进行对照测试，但应记录修改前后的解析结果，并确认问题是否只影响容器。DNS 修改不能修复端口转发、路由黑洞、MTU 不匹配或真实丢包。

如果怀疑 MTU，先查看容器接口和 Docker 网络配置，再进行分片或路径 MTU 对照测试。Docker 官方文档提供了自定义 bridge 网络 MTU 的配置项；修改后通常需要重新创建相关网络或服务，且不同隧道、云网络和物理链路的合适值可能不同。本文不提供未经测试的固定 MTU 数值。

对于多个服务共同运行的场景，可以在 Compose 中声明用户自定义网络，让服务通过名称互相访问；如果只是 Transmission 单容器，保持配置简单通常更利于定位问题。

配置文件修改、升级与恢复

LinuxServer.io 的镜像说明要求在编辑 /config 中的 settings.json 前先停止容器，否则运行中的 Transmission 可能覆盖手动修改。建议先备份，再逐项调整：

docker compose stop transmission
cp /srv/transmission/config/settings.json /srv/transmission/config/settings.json.bak
nano /srv/transmission/config/settings.json
docker compose up -d transmission

Transmission 官方配置文档说明，Transmission 4.1.0 开始逐步转向使用 snake_case 配置字段；旧的 kebab-case 字段在 Transmission 4 中仍是默认形式，但已标记为弃用，Transmission 5 将采用新的默认形式。不要把不同主版本教程中的字段混合复制，先查看当前生成的配置结构，再修改明确需要的项目。参考：Transmission 配置文件文档。

升级前备份 Compose 文件和 /srv/transmission/config，升级后检查容器日志、Web 登录、下载路径、peer port 和 DNS。若升级后出现连接异常，先判断是镜像进程问题、配置格式问题，还是网络层问题，不要直接删除整个配置目录。

transmission docker 部署后的快速检查清单

  1. 运行 docker compose config，确认 YAML 结构和变量没有明显错误。
  2. 运行 docker compose ps，确认容器持续运行而不是反复重启。
  3. 检查 /config、/downloads 和可选 /watch 的挂载关系与写入权限。
  4. 使用本机地址测试 Web/RPC 端口，再从其他设备测试实际访问路径。
  5. 确认 PEERPORT 与 TCP/UDP 端口映射一致。
  6. 如果连接失败，分别验证 DNS、出站访问、MTU、宿主机防火墙、路由器转发和上游 NAT。
  7. 记录每次修改前后的日志、解析结果、延迟和丢包现象，避免同时改动多个变量。

最重要的边界是：容器 running 不代表外部网络正常；Web UI 可访问不代表 peer port 已开放；DNS 正常也不代表路径没有丢包或 MTU 问题。按应用层、容器层、宿主机层、路由层和上游线路逐层验证，通常比直接重装更容易找到原因。

常见问题 FAQ

transmission docker 需要在宿主机再安装 Transmission 吗？

通常不需要。使用容器镜像时，Transmission 服务由容器中的程序提供；宿主机主要负责运行 Docker、保存挂载目录、提供网络和存储资源。具体镜像的启动参数仍应以维护者文档为准。

为什么 Web UI 能打开，但下载任务仍然没有连接？

Web UI 使用的是管理端口，下载节点连接使用 peer port，两者相互独立。请检查 PEERPORT、TCP/UDP 映射、宿主机防火墙、路由器转发、多层 NAT 和上游网络，不要把 Web 页面可访问当成节点端口已开放。

容器无法解析域名，是否应该马上更换 DNS？

先确认问题确实发生在 DNS：比较宿主机和容器内的解析结果，查看容器的 /etc/resolv.conf 和日志，再用 Compose 的 dns 配置做对照测试。更换 DNS 无法解决端口阻断、MTU 不匹配或线路丢包。

什么时候需要调整 Docker 的 MTU？

只有在存在路径测试、对照结果或明确的隧道网络背景时才考虑。部分 HTTPS 连接卡住、特定目标超时或经过隧道后出现分片异常，可能提示 MTU 问题；应先确认宿主机和 Docker 网络的实际配置，再逐步测试，不要直接套用固定数值。

可以直接使用 network_mode: host 吗？

可以作为特定场景的排查或部署选项，但它会让容器共享宿主机网络栈，并改变端口映射、隔离和安全边界。单容器基础部署通常先使用默认 bridge 网络和明确的端口映射，只有确认确有需求时再评估 host 模式。

修改 settings.json 后为什么没有生效？

LinuxServer.io 文档说明，编辑该文件前应停止容器，否则运行中的 Transmission 可能覆盖修改。先停止容器、备份文件，再修改并重新启动；同时注意 Transmission 4 与后续版本的配置字段格式可能不同。

常见问题

transmission docker 需要在宿主机再安装 Transmission 吗？

通常不需要。容器镜像已经提供 Transmission 服务，宿主机只需要运行 Docker，并准备挂载目录、网络和存储资源。

为什么 Web UI 能打开，但下载任务仍然没有连接？

Web UI 使用管理端口，下载节点使用 peer port。应检查 PEERPORT、TCP/UDP 映射、宿主机防火墙、路由器转发、多层 NAT 和上游网络。

容器无法解析域名，是否应该马上更换 DNS？

先比较宿主机和容器内的解析结果，确认问题确实属于 DNS，再使用 Compose 的 dns 配置做对照测试。DNS 修改不能解决端口阻断、MTU 不匹配或线路丢包。

什么时候需要调整 Docker 的 MTU？

只有在路径测试、对照结果或明确隧道网络背景支持时才考虑。应先查看宿主机和 Docker 网络配置，再逐步测试，不要直接套用固定数值。

可以直接使用 network_mode: host 吗？

可以作为特定场景的选项，但会共享宿主机网络栈并改变端口映射和隔离边界。基础部署通常先使用默认 bridge 网络和明确端口映射。

修改 settings.json 后为什么没有生效？

编辑前应停止容器并备份文件，否则运行中的 Transmission 可能覆盖修改；同时要注意不同主版本的配置字段格式可能不同。

相关阅读

参考资料

  1. LinuxServer.io Transmission 镜像说明
  2. Transmission 官方 Web 界面文档
  3. Transmission 官方端口转发指南
  4. Transmission 官方配置文件文档
  5. Docker Compose services 文档
  6. Docker bridge 网络文档
  7. Docker Compose 网络文档