企业官网建设流程全解析

1. 新手在 Ubuntu 上装 dify 到底难在哪：从零跑通 dify + MySQL 的完整链路

如果你刚接触 Linux，看到「dify 安装」「Ubuntu Docker 部署」「MySQL 连接配置」这几个词凑在一起，第一反应大概是：这得装多少东西？其实我一开始也这么想，真正动手之后发现，dify 官方已经把容器编排这件事做得相当到位，你需要的只是把几个关键环节串起来——Docker 环境、dify 本体、MySQL 服务、以及让 dify 里的 Agent 能通过 MCP 协议读到 MySQL 的数据。

dify 是什么？简单说，它是一个开源的 LLM 应用开发平台，你可以用可视化界面搭聊天助手、工作流、Agent，底层可以接各种大模型。它适合谁？适合想快速验证 AI 应用想法、又不想从零写后端的前端或全栈开发者，也适合运维同学拿来搭内部工具。而 MySQL 连接这一环，解决的是「让 AI 能查你的业务数据库」这个高频需求。

这篇内容面向的是刚摸 Ubuntu 的新手，所以我会把每一步的命令、配置文件、验证方式都写清楚。整个链路分六块：先讲清楚问题和场景，再把 TaoToken 统一 Key 的前置准备做好，然后给出可复制的 docker-compose 和环境变量配置，接着验证请求是否成功，再把我踩过的报错逐个排查，最后给你一个稳定的凭据管理入口。你跟着做，目标是独立跑出一套可运行、可验证的 dify + MySQL 本地环境。

先说清楚一个前提：dify 默认自带的是 PostgreSQL，不是 MySQL。所以「dify 连接 MySQL」这件事，本质上不是改 dify 的主数据库，而是通过 MCP（Model Context Protocol）服务器，让 dify 里的 Agent 能访问你另外部署的 MySQL。这个区分很重要，很多新手一上来就想把 dify 的 db 换成 MySQL，结果把容器搞崩了。我们走的是 MCP 这条路，干净、可回滚。

环境要求不高：Ubuntu 20.04 或 22.04 都行，内存建议 8G 以上（dify 全家桶容器不少），磁盘留 20G。Docker 和 Docker Compose 插件提前装好，这是唯一的前置依赖。下面正式开始。

2. TaoToken 前置准备：统一管理 dify 里的模型调用凭据

在动手装 dify 之前，我建议你先把模型调用的凭据问题解决掉。原因很现实：dify 里要配大模型，Agent 要调模型，MCP 服务器背后也可能要模型能力，如果你每个地方都填一遍不同的 Key，后面排查问题时会非常痛苦——到底是 Key 失效了，还是模型 ID 写错了，还是额度没了？

TaoToken 在这里扮演的角色，是一个统一的 API 通道和 Key 管理入口。你可以把它理解成一个「模型调用的总闸」：申请一个 Key，配置一个 Base URL，然后在 dify、Cline、Codex 这些工具里都填同一套凭据。这样出问题时你只需要检查一个地方。

具体怎么做？先访问官网 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 注册账号，然后进控制台 https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_content=console&utm_campaign=rewrite 创建 API Key。创建完之后，你会拿到两样东西：一个是 Key（形如 sk-xxxx），一个是 Base URL。Base URL 统一用 https://taotoken.net/api，注意这个地址后面不加任何 UTM 参数，直接填就行。

拿到 Key 之后，建议你先在「模型对话」页面 https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_content=model_chat&utm_campaign=rewrite 里发一条消息，确认这个 Key 是通的、额度是有的。这一步花不了一分钟，但能帮你排除掉后面 80% 的「模型调用失败」问题。我试过跳过这步，结果在 dify 里折腾半天，最后发现是 Key 没激活。

如果你后面打算长期跑编码类 Agent，或者要做复杂的多步工作流，可以了解一下 Coding Plan https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding_plan&utm_campaign=rewrite，它更适合高频、长链路的调用场景。而如果你只是想先跑通 dify + MySQL 这条链路，用按量计费的普通 Key 就够了。

这里要强调一个配置原则：Base URL、API Key、Model ID 这三件套，在任何工具里都必须同时正确。少一个、错一个，都会报错。后面在 dify 里配模型、在 MCP 服务器里配模型，我都会反复提到这三件套，你记牢这个结构，排查会快很多。

另外，TaoToken 的接入文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite，里面有各工具的详细配置示例，遇到不确定的字段可以去对照。API Keys 管理页在 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite，随时可以新建或吊销 Key。

前置准备做完，你手里应该有了：一个可用的 API Key、Base URL（https://taotoken.net/api）、以及一个确认能调通的模型 ID（比如 gpt-4o-mini 或 claude-3-5-sonnet 这类，具体以你账号里可用的为准）。下面进入 dify 的安装。

3. 可复制配置：Ubuntu 下 dify 的 docker-compose 与环境变量

这一节是全文的技术核心，我会给出完整的命令和配置文件片段，你直接复制改改就能用。

3.1 安装 Docker 与 Compose 插件

如果你还没装 Docker，先执行：

sudo apt update sudo apt install -y docker.io docker-compose-plugin sudo systemctl enable --now docker sudo usermod -aG docker $USER

最后一行是把你当前用户加进 docker 组，执行完要重新登录一次终端才生效。验证：

docker --version docker compose version

两条都能输出版本号，说明环境 OK。

3.2 拉取 dify 代码

选一个你习惯的目录，比如 /home/youruser，然后：

cd /home/youruser git clone https://github.com/langgenius/dify.git --branch 1.1.0 cd dify/docker

这里指定了 1.1.0 分支，版本明确，避免 main 分支变动带来的意外。进入 docker 目录后，你会看到 .env.example、docker-compose.yaml 这些文件。

3.3 准备环境变量

cp .env.example .env

然后编辑 .env，重点改这几个地方（其他保持默认即可）：

# .env 关键片段 EXPOSE_NGINX_PORT=80 EXPOSE_NGINX_SSL_PORT=443 # 数据库保持默认的 postgres，不要改成 mysql DB_TYPE=postgresql # 如果你要接外部模型，可以在 dify 界面里配，不必写在这里

注意：dify 主库不要动，保持 postgres。我们要连的 MySQL 是独立部署的另一个服务。

3.4 启动 dify

docker compose up -d

这条命令会拉起 api、worker、web、db、redis、nginx、weaviate、sandbox、ssrf_proxy、plugin_daemon 等一堆容器。第一次拉镜像会慢，耐心等。启动完验证：

docker compose ps

你应该看到类似这样的输出（节选）：

NAME IMAGE STATUS docker-api-1 langgenius/dify-api:1.2.0 Up docker-db-1 postgres:15-alpine Up (healthy) docker-nginx-1 nginx:latest Up 0.0.0.0:80->80/tcp docker-redis-1 redis:6-alpine Up (healthy) docker-web-1 langgenius/dify-web:1.2.0 Up docker-worker-1 langgenius/dify-api:1.2.0 Up

只要 STATUS 都是 Up，没有反复重启，就说明 dify 本体起来了。浏览器访问 http://localhost:3000（如果你改了端口就用改后的），首次进入会让你设置管理员账号，按提示填完即可。

3.5 部署 MySQL 并建库

MySQL 你可以用 Docker 单独跑，也可以装在宿主机。用 Docker 更干净：

docker run -d \ --name mysql-for-dify \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD=YourStrongPass123 \ -e MYSQL_DATABASE=test \ -v /home/youruser/mysql-data:/var/lib/mysql \ mysql:8.0

进去建一张测试表，方便后面验证：

docker exec -it mysql-for-dify mysql -uroot -pYourStrongPass123

CREATE DATABASE IF NOT EXISTS test; USE test; CREATE TABLE users ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50), email VARCHAR(100) ); INSERT INTO users (name, email) VALUES ('Alice', 'alice@example.com'), ('Bob', 'bob@example.com');

3.6 配置 MCP 服务器连接 MySQL

克隆 MySQL MCP 服务器：

cd /home/youruser git clone https://github.com/wenb1n-dev/mysql_mcp_server_pro cd mysql_mcp_server_pro

编辑 docker-compose.yml，填入你的数据库信息：

version: '3.8' services: mysql-mcp-server: build: context: . dockerfile: Dockerfile container_name: mysql-mcp-server ports: - "9000:9000" environment: MYSQL_HOST: 192.168.1.100 MYSQL_PORT: 3306 MYSQL_USER: root MYSQL_PASSWORD: YourStrongPass123 MYSQL_DATABASE: test MYSQL_ROLE: admin PYTHONPATH: /app/src restart: always command: ["python", "-m", "mysql_mcp_server_pro.server"]

把 MYSQL_HOST 换成你宿主机的实际 IP（用ip addr或hostname -I查），不要写 localhost，因为容器里访问不到宿主机的 localhost。然后：

docker compose up -d docker compose logs -f

看到服务监听 9000 端口、没有报错，就说明 MCP 服务器起来了。

3.7 在 dify 里配置模型与 MCP

登录 dify，进入「设置 → 模型供应商」，选择 OpenAI 兼容方式，填入三件套：

• Base URL：https://taotoken.net/api
• API Key：你的 TaoToken Key
• Model ID：你确认可用的模型名

保存后测试连接，通了再继续。

然后进「插件」，搜索 MCP SSE 相关插件并安装。安装后在插件配置里填入 MCP 服务器地址：

{"mysql_mcp_server_pro":{"url":"http://192.168.1.100:9000/sse"}}

保存显示成功，说明 dify 已经能通过 SSE 和 MCP 服务器通信。

3.8 创建 Agent 并测试

新建一个空白 Agent 应用，在提示词里写清楚你的表结构，比如「test 库有 users 表，字段为 id、name、email」，然后添加 MCP 工具，选择刚才配的 mysql_mcp_server_pro。右上角选好模型，发一条「查一下 users 表里有哪些人」，如果返回 Alice 和 Bob，整条链路就通了。

4. 验证请求：确认 dify、MySQL、MCP 三段都真的通了

配置写完不代表通了，必须逐段验证。我习惯分三层查：MySQL 本身、MCP 服务器、dify 到 MCP。

第一层，MySQL 是否可连。在宿主机执行：

mysql -h192.168.1.100 -uroot -pYourStrongPass123 -e "SELECT * FROM test.users;"

能列出两行数据，说明 MySQL 和网络没问题。如果这里就失败，先别往下走，检查 MySQL 容器是否在跑、端口是否映射、防火墙是否放行 3306。

第二层，MCP 服务器是否健康。执行：

curl -v http://192.168.1.100:9000/sse

SSE 接口会保持连接并持续输出，你看到 HTTP 200 和事件流开头就说明服务正常。如果 curl 卡住不动或报 connection refused，检查容器日志：

docker logs mysql-mcp-server --tail 50

常见的是数据库连接失败，日志里会明确写 access denied 或 can't connect。

第三层，dify 到 MCP。在 dify 的 Agent 里发测试消息，观察返回。如果 Agent 说「无法访问工具」或「工具调用失败」，回到插件配置页看 MCP 地址是否写对、是否显示已授权。这一步最容易出问题的是 IP 写成了 localhost，或者防火墙拦了 9000 端口。

三层都通之后，你可以做一个更真实的验证：在 MySQL 里再插一条数据，然后在 dify Agent 里问「现在 users 表有几条记录」，如果返回 3，说明是实时读取，不是缓存。这个测试很有价值，能确认整条链路是活的。

关于模型调用这一段的验证，如果你在 dify 里配的是 TaoToken 的通道，可以顺便在「模型对话」页面 https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_content=model_chat&utm_campaign=rewrite 发一条同样的提示，对比两边返回是否一致。如果 dify 里报模型错误但对话页面正常，那问题就在 dify 的模型配置字段，不在 Key 本身。

验证通过后，建议把关键配置记下来：MySQL 的 host/port/user/db、MCP 的 SSE 地址、dify 的模型三件套。后面迁移或重建环境时，照着填就行。

5. 本篇常见错排查：401、local proxy failed、reading choices、OAuth 逐个拆

这一节把我实际遇到和社群里高频出现的报错列出来，对照着查。

401 Unauthorized。这个几乎都是 Key 问题。可能原因：Key 复制时带了空格、Key 被吊销、Base URL 写错导致请求打到了别的服务。排查方法：先在模型对话页面确认 Key 可用，再检查 dify 里 Base URL 是否是 https://taotoken.net/api，注意结尾不要多斜杠。如果用的是 Coding Plan 的 Key，确认它和普通 Key 的适用范围是否一致。

local proxy failed / connection refused。这个通常出现在 MCP 连接环节。dify 容器访问 MCP 服务器时，如果 MCP 地址写的是 127.0.0.1 或 localhost，容器内部会指向自己，当然连不上。改成宿主机真实 IP。另外检查 MCP 容器是否真的在监听 0.0.0.0:9000，而不是只监听 127.0.0.1。docker-compose 里 ports 映射写 "9000:9000" 默认就是对外，但如果服务本身绑定 127.0.0.1，外部还是进不来。

reading choices 相关报错。这类错误一般出现在模型返回格式不符合预期时，比如你填的 Model ID 实际不支持 chat completions 接口，或者返回体结构变了。排查：换一个确认支持的模型 ID 试；检查请求是否被中间层改写。如果你用的是统一通道，确认该模型 ID 在通道侧是开放的。

OAuth 报错。如果你在配置某些插件或 CLI 工具时看到 OAuth 相关失败，先确认是不是把需要 OAuth 的工具和 API Key 方式混用了。dify 里配模型走的是 API Key，不需要 OAuth。如果你在配 Claude Code 这类工具，它可能走 Anthropic 兼容接口，配置方式不同，参考接入文档 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite 里的对应章节。

防火墙问题。这个我必须单独说，因为太隐蔽了。我遇到过 MCP 明明配好了，突然连不上，查了半天发现是后来装的某个面板工具把防火墙重新打开了。Ubuntu 上用：

sudo ufw status

如果显示 active，要么关掉sudo ufw disable，要么放行端口sudo ufw allow 9000/tcp和sudo ufw allow 3306/tcp。生产环境建议放行而不是关闭，本地测试图省事关掉也行。

容器反复重启。docker compose ps里看到 Restarting，先看日志docker compose logs <服务名>。dify 的 api 容器重启常见原因是 .env 里数据库配置被改错，或者内存不足被 OOM kill。8G 内存是底线，16G 更稳。

MCP 显示未授权。在 dify 插件页看到未授权，通常是 MCP 服务器地址填错或服务没起来。先用 curl 确认 SSE 地址可访问，再回填。保存后如果还显示未授权，刷新页面或重新保存一次。

排查的核心思路是分层：先确认最底层服务活着，再确认网络可达，最后确认配置字段正确。不要一上来就怀疑 dify 本身，大部分问题都在网络和字段上。

6. 稳定跑起来之后：把凭据入口固定下来

整套环境跑通之后，你会发现真正需要长期维护的其实不是 dify 或 MySQL 本身，而是模型调用的凭据。dify 升级、MCP 服务器换版本、你新加一个 Agent 应用，每次都要填 Key 和 Base URL。如果这些凭据散落在各处，改一次要翻好几个配置文件。

我的做法是把 TaoToken 作为唯一的凭据入口。所有需要模型能力的地方——dify 的模型供应商、MCP 服务器里的模型调用、你本地用的编码工具——都指向同一个 Base URL 和同一套 Key。这样轮换 Key 的时候只改一处，排查问题时也只需要确认一个通道是否正常。

具体操作上，API Keys 管理页 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite 可以按用途建多个 Key，比如 dify 用一个、本地开发用一个，互不影响。如果某个 Key 泄露或异常，单独吊销即可，不会波及全部环境。接入文档 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite 里有各工具的字段对照，换工具时照着填。

如果你后面要把这套环境用于长期的编码 Agent 或自动化工作流，Coding Plan https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding_plan&utm_campaign=rewrite 在调用频率和成本上会更合适。而日常验证模型是否正常，直接用模型对话页面最快。

最后给你一个实用习惯：每次改完配置，先跑一遍第 4 节的三层验证，再去做业务逻辑。这样能把问题挡在配置层，不会等到 Agent 跑一半才报错。环境这东西，稳比快重要。