企业官网建设流程全解析

背景

本次联调场景：

• 后端机器：192.168.2.237:5001
• 前端同事机器：192.168.2.218:3000
• 前端 dev-proxy 预期地址：192.168.2.218:5001
• 出问题接口：/console/api/account/profile

前端最初访问：

http://192.168.2.218:5001/console/api/account/profile

一直失败。

最后确认：不是后端接口代码问题，而是联调环境里依次踩到了三个问题：

1. 192.168.2.218:5001没有进程监听。
2. dev-proxy 启动后 CORS 允许来源不对。
3. 登录成功后profile401，本质是 cookie 登录态没有正确落到同一个访问链路。

最终结论

前端页面、API 代理、后端服务的关系要清楚：

浏览器 -> http://192.168.2.218:3000 前端页面 -> http://192.168.2.218:5001/console/api 前端 dev-proxy -> http://192.168.2.237:5001/console/api 后端 Flask API

如果前端配置让浏览器请求192.168.2.218:5001，那么2.218 机器上必须真的启动 dev-proxy 并监听 5001。

如果不想跑 dev-proxy，就让前端直接请求后端：

http://192.168.2.237:5001/console/api

不要让浏览器请求一个没人监听的地址。

问题一：192.168.2.218:5001根本没服务

现象

从后端机器访问：

Test-NetConnection192.168.2.218-Port 5001

结果：

TcpTestSucceeded: False

接口请求：

Invoke-WebRequesthttp://192.168.2.218:5001/console/api/account/profile

报：

无法连接到远程服务器

根因

前端同事机器执行：

netstat-ano|findstr :5001

返回空，说明2.218:5001没有任何进程监听。

而后端机器执行：

TCP 0.0.0.0:5001 LISTENING

说明真正监听 5001 的是后端机器192.168.2.237，不是前端机器192.168.2.218。

解决

前端同事需要启动 dev-proxy：

pnpm-Cweb run dev:proxy

并确保web/.env.local里是：

DEV_PROXY_HOST=0.0.0.0 DEV_PROXY_PORT=5001 DEV_PROXY_TARGET=http://192.168.2.237:5001 DEV_PROXY_PUBLIC_TARGET=http://192.168.2.237:5001

再次执行：

netstat-ano|findstr :5001

应该看到：

0.0.0.0:5001 LISTENING

如果是：

127.0.0.1:5001 LISTENING

说明只能本机访问，局域网其他机器访问不了。

问题二：DEV_PROXY_HOST=127.0.0.1只能本机访问

含义

DEV_PROXY_HOST=127.0.0.1

表示 dev-proxy 只监听本机回环地址。

也就是说只有前端同事自己机器能访问：

http://127.0.0.1:5001

其他机器访问：

http://192.168.2.218:5001

会失败。

正确配置

DEV_PROXY_HOST=0.0.0.0

含义是监听所有网卡，包括局域网 IP：

192.168.2.218:5001

问题三：system-features200，但浏览器 CORS 报错

现象

接口：

http://192.168.2.218:5001/console/api/system-features

命令行请求返回 200，但浏览器仍报错。

浏览器里看到：

Referrer Policy: strict-origin-when-cross-origin

这行本身不是错误，只是浏览器默认策略提示。

真正的问题是 CORS。

排查结果

直接请求后端：

http://192.168.2.237:5001/console/api/system-features Origin: http://192.168.2.218:3000

后端返回：

Access-Control-Allow-Origin: http://192.168.2.218:3000

说明后端 CORS 是对的。

但经过 dev-proxy：

http://192.168.2.218:5001/console/api/system-features Origin: http://192.168.2.218:3000

返回变成：

Access-Control-Allow-Origin: http://192.168.2.237:5001

这和浏览器页面来源不一致：

http://192.168.2.218:3000

浏览器会拦截。

解决

前端同事需要在web/dev-proxy.config.ts里加：

cors:{allowedOrigins:['http://192.168.2.218:3000',],},

注意：

NEXT_ALLOWED_DEV_ORIGINS=192.168.2.218

管的是 Next dev server，不管@langgenius/dev-proxy的 CORS。

问题四：登录接口 200，但/account/profile401

现象

后端日志：

POST /console/api/login 200 GET /console/api/account/profile 401 POST /console/api/refresh-token 401

含义

登录接口成功了，但后续请求没有带上有效的：

• access_token
• refresh_token

所以/account/profile报 401。

常见原因

前端页面和 API 不是同一个 host。

比如：

前端页面：http://192.168.2.218:3000 后端 API：http://192.168.2.237:5001

Dify 默认：

COOKIE_DOMAIN=

表示 cookie 绑定当前响应 host。

如果登录请求和 profile 请求不在同一个稳定链路下，浏览器可能不会把登录 cookie 带到后续请求里。

推荐解决

让浏览器统一请求前端同事机器上的 dev-proxy：

前端页面：http://192.168.2.218:3000 API 请求：http://192.168.2.218:5001/console/api dev-proxy 转发到：http://192.168.2.237:5001/console/api

这样浏览器看到的是统一的192.168.2.218，cookie 更容易正常工作。

前端需要做的事情

1.web/.env.local

推荐配置：

CONSOLE_API_URL=http://192.168.2.237:5001 NEXT_PUBLIC_API_PREFIX=http://192.168.2.218:5001/console/api NEXT_PUBLIC_PUBLIC_API_PREFIX=http://192.168.2.218:5001/api NEXT_PUBLIC_SOCKET_URL=ws://192.168.2.218:5001 DEV_PROXY_TARGET=http://192.168.2.237:5001 DEV_PROXY_PUBLIC_TARGET=http://192.168.2.237:5001 DEV_PROXY_HOST=0.0.0.0 DEV_PROXY_PORT=5001

2.web/dev-proxy.config.ts

需要允许前端页面来源：

exportdefault{server:{host:DEV_PROXY_HOST,port:DEV_PROXY_PORT,},cors:{allowedOrigins:['http://192.168.2.218:3000',],},routes:[// 原 routes 保持不变],}satisfies DevProxyConfig

3. 重启服务

修改 env 或 proxy config 后，需要重启：

pnpm-Cweb run dev:proxypnpm-Cweb run dev

4. 检查端口

在前端机器执行：

netstat-ano|findstr :5001

正确结果应该包含：

0.0.0.0:5001 LISTENING

后端需要做的事情

1. Flask 必须监听局域网地址

后端启动需要类似：

flask run--host0.0.0.0--port5001--debug

日志里看到：

Running on all addresses (0.0.0.0)

说明不是只监听127.0.0.1。

2. 后端.env推荐配置

本次联调推荐：

CONSOLE_API_URL=http://192.168.2.218:5001 CONSOLE_WEB_URL=http://192.168.2.218:3000 APP_WEB_URL=http://192.168.2.218:3000 CONSOLE_CORS_ALLOW_ORIGINS=http://192.168.2.218:3000,* WEB_API_CORS_ALLOW_ORIGINS=http://192.168.2.218:3000,* COOKIE_DOMAIN=

说明：

• CONSOLE_WEB_URL：后端认为 Console 前端页面在哪里。
• CONSOLE_API_URL：后端对外暴露的 Console API 地址。使用 dev-proxy 时，可以写前端同事的代理地址。
• CONSOLE_CORS_ALLOW_ORIGINS：允许访问 Console API 的前端来源。
• COOKIE_DOMAIN=：保持空，使用当前 host 绑定 cookie。

3. 后端接口状态判断

未登录直接请求：

Invoke-WebRequesthttp://192.168.2.237:5001/console/api/account/profile

返回 401 是正常的。

因为接口有登录要求：

/console/api/account/profile -> setup_required -> login_required -> account_initialization_required

只要不是“无法连接远程服务器”，就说明网络链路已经通了。

常用排查命令

检查端口是否通

Test-NetConnection192.168.2.218-Port 5001

结果含义：

TcpTestSucceeded: False

表示端口不通，优先查监听、防火墙、进程是否启动。

TcpTestSucceeded: True

表示网络层通了，再看 HTTP 状态码、CORS、cookie。

检查本机监听

netstat-ano|findstr :5001

结果含义：

0.0.0.0:5001 LISTENING

局域网可访问。

127.0.0.1:5001 LISTENING

只有本机可访问。

空结果表示没有服务监听 5001。

检查接口

Invoke-WebRequesthttp://192.168.2.218:5001/console/api/system-features

200表示基础接口通。

Invoke-WebRequesthttp://192.168.2.218:5001/console/api/account/profile

未登录返回401是正常的。

配置项速查

最终经验

这类问题不要一上来改接口代码。

按顺序排：

1. 端口是否监听。
2. 局域网是否能连。
3. dev-proxy 是否启动。
4. CORS 头是否等于页面 origin。
5. 登录 cookie 是否被后续请求带上。
6. 最后才看后端接口逻辑。

本次最终能登录，说明：

• 后端/console/api/account/profile接口没问题。
• 后端 CORS 配置没问题。
• 主要问题在前端 dev-proxy 的启动、监听地址和 CORS 允许来源。