ishenwei/nexus
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Auto-sync: 2026-04-21 16:03

Browse Source
This commit is contained in:
weishen
2026-04-21 16:03:27 +08:00
parent b3b6be6114
commit 914c8f6925
42 changed files with 3923 additions and 1592 deletions
Download Patch File Download Diff File Expand all files Collapse all files

256
raw/Agent/Open WebUI Hermes Agent.md Normal file
View File

@@ -0,0 +1,256 @@
---
title: "Open WebUI | Hermes Agent"
source: "https://hermes-agent.nousresearch.com/docs/user-guide/messaging/open-webui?_highlight=api_server_enabled#hermes-agent-api-server"
author:
published:
created: 2026-04-20
description: "Connect Open WebUI to Hermes Agent via the OpenAI-compatible API server"
tags:
- "clippings"
---
[Open WebUI](https://github.com/open-webui/open-webui) (126k★) is the most popular self-hosted chat interface for AI. With Hermes Agent's built-in API server, you can use Open WebUI as a polished web frontend for your agent — complete with conversation management, user accounts, and a modern chat interface.
## Architecture
Open WebUI connects to Hermes Agent's API server just like it would connect to OpenAI. Your agent handles the requests with its full toolset — terminal, file operations, web search, memory, skills — and returns the final response.
Open WebUI talks to Hermes server-to-server, so you do not need `API_SERVER_CORS_ORIGINS` for this integration.
## Quick Setup
### 1\. Enable the API server
Add to `~/.hermes/.env`:
```bash
API_SERVER_ENABLED=true
API_SERVER_KEY=your-secret-key
```
### 2\. Start Hermes Agent gateway
```bash
hermes gateway
```
You should see:
```markdown
[API Server] API server listening on http://127.0.0.1:8642
```
### 3\. Start Open WebUI
```bash
docker run -d -p 3000:8080 \
-e OPENAI_API_BASE_URL=http://host.docker.internal:8642/v1 \
-e OPENAI_API_KEY=your-secret-key \
--add-host=host.docker.internal:host-gateway \
-v open-webui:/app/backend/data \
--name open-webui \
--restart always \
ghcr.io/open-webui/open-webui:main
```
### 4\. Open the UI
Go to **[http://localhost:3000](http://localhost:3000/)**. Create your admin account (the first user becomes admin). You should see your agent in the model dropdown (named after your profile, or **hermes-agent** for the default profile). Start chatting!
## Docker Compose Setup
For a more permanent setup, create a `docker-compose.yml`:
```yaml
services:
open-webui:
image: ghcr.io/open-webui/open-webui:main
ports:
- "3000:8080"
volumes:
- open-webui:/app/backend/data
environment:
- OPENAI_API_BASE_URL=http://host.docker.internal:8642/v1
- OPENAI_API_KEY=your-secret-key
extra_hosts:
- "host.docker.internal:host-gateway"
restart: always
volumes:
open-webui:
```
Then:
```bash
docker compose up -d
```
## Configuring via the Admin UI
If you prefer to configure the connection through the UI instead of environment variables:
1. Log in to Open WebUI at **[http://localhost:3000](http://localhost:3000/)**
2. Click your **profile avatar** → **Admin Settings**
3. Go to **Connections**
4. Under **OpenAI API**, click the **wrench icon** (Manage)
5. Click **\+ Add New Connection**
6. Enter:
- **URL**: `http://host.docker.internal:8642/v1`
- **API Key**: your key or any non-empty value (e.g., `not-needed`)
7. Click the **checkmark** to verify the connection
8. **Save**
Your agent model should now appear in the model dropdown (named after your profile, or **hermes-agent** for the default profile).
> [!-warning] -warning
> warning
>
> Environment variables only take effect on Open WebUI's **first launch**. After that, connection settings are stored in its internal database. To change them later, use the Admin UI or delete the Docker volume and start fresh.
## API Type: Chat Completions vs Responses
Open WebUI supports two API modes when connecting to a backend:
| Mode | Format | When to use |
| --- | --- | --- |
| **Chat Completions** (default) | `/v1/chat/completions` | Recommended. Works out of the box. |
| **Responses** (experimental) | `/v1/responses` | For server-side conversation state via `previous_response_id`. |
### Using Chat Completions (recommended)
This is the default and requires no extra configuration. Open WebUI sends standard OpenAI-format requests and Hermes Agent responds accordingly. Each request includes the full conversation history.
### Using Responses API
To use the Responses API mode:
1. Go to **Admin Settings** → **Connections** → **OpenAI** → **Manage**
2. Edit your hermes-agent connection
3. Change **API Type** from "Chat Completions" to **"Responses (Experimental)"**
4. Save
With the Responses API, Open WebUI sends requests in the Responses format (`input` array + `instructions`), and Hermes Agent can preserve full tool call history across turns via `previous_response_id`. When `stream: true`, Hermes also streams spec-native `function_call` and `function_call_output` items, which enables custom structured tool-call UI in clients that render Responses events.
> [!-secondary] -secondary
> note
>
> Open WebUI currently manages conversation history client-side even in Responses mode — it sends the full message history in each request rather than using `previous_response_id`. The main advantage of Responses mode today is the structured event stream: text deltas, `function_call`, and `function_call_output` items arrive as OpenAI Responses SSE events instead of Chat Completions chunks.
## How It Works
When you send a message in Open WebUI:
1. Open WebUI sends a `POST /v1/chat/completions` request with your message and conversation history
2. Hermes Agent creates an AIAgent instance with its full toolset
3. The agent processes your request — it may call tools (terminal, file operations, web search, etc.)
4. As tools execute, **inline progress messages stream to the UI** so you can see what the agent is doing (e.g. `` `💻 ls -la` ``, `` `🔍 Python 3.12 release` ``)
5. The agent's final text response streams back to Open WebUI
6. Open WebUI displays the response in its chat interface
Your agent has access to all the same tools and capabilities as when using the CLI or Telegram — the only difference is the frontend.
> [!-success] -success
> Tool Progress
>
> With streaming enabled (the default), you'll see brief inline indicators as tools run — the tool emoji and its key argument. These appear in the response stream before the agent's final answer, giving you visibility into what's happening behind the scenes.
## Configuration Reference
### Hermes Agent (API server)
| Variable | Default | Description |
| --- | --- | --- |
| `==API_SERVER_ENABLED==` | `false` | Enable the API server |
| `API_SERVER_PORT` | `8642` | HTTP server port |
| `API_SERVER_HOST` | `127.0.0.1` | Bind address |
| `API_SERVER_KEY` | *(required)* | Bearer token for auth. Match `OPENAI_API_KEY`. |
### Open WebUI
| Variable | Description |
| --- | --- |
| `OPENAI_API_BASE_URL` | Hermes Agent's API URL (include `/v1`) |
| `OPENAI_API_KEY` | Must be non-empty. Match your `API_SERVER_KEY`. |
## Troubleshooting
### No models appear in the dropdown
- **Check the URL has `/v1` suffix**: `http://host.docker.internal:8642/v1` (not just `:8642`)
- **Verify the gateway is running**: `curl http://localhost:8642/health` should return `{"status": "ok"}`
- **Check model listing**: `curl http://localhost:8642/v1/models` should return a list with `hermes-agent`
- **Docker networking**: From inside Docker, `localhost` means the container, not your host. Use `host.docker.internal` or `--network=host`.
### Connection test passes but no models load
This is almost always the missing `/v1` suffix. Open WebUI's connection test is a basic connectivity check — it doesn't verify model listing works.
### Response takes a long time
Hermes Agent may be executing multiple tool calls (reading files, running commands, searching the web) before producing its final response. This is normal for complex queries. The response appears all at once when the agent finishes.
### "Invalid API key" errors
Make sure your `OPENAI_API_KEY` in Open WebUI matches the `API_SERVER_KEY` in Hermes Agent.
## Multi-User Setup with Profiles
To run separate Hermes instances per user — each with their own config, memory, and skills — use [profiles](https://hermes-agent.nousresearch.com/docs/user-guide/profiles). Each profile runs its own API server on a different port and automatically advertises the profile name as the model in Open WebUI.
### 1\. Create profiles and configure API servers
```bash
hermes profile create alice
hermes -p alice config set API_SERVER_ENABLED true
hermes -p alice config set API_SERVER_PORT 8643
hermes -p alice config set API_SERVER_KEY alice-secret
hermes profile create bob
hermes -p bob config set API_SERVER_ENABLED true
hermes -p bob config set API_SERVER_PORT 8644
hermes -p bob config set API_SERVER_KEY bob-secret
```
### 2\. Start each gateway
```bash
hermes -p alice gateway &
hermes -p bob gateway &
```
### 3\. Add connections in Open WebUI
In **Admin Settings** → **Connections** → **OpenAI API** → **Manage**, add one connection per profile:
| Connection | URL | API Key |
| --- | --- | --- |
| Alice | `http://host.docker.internal:8643/v1` | `alice-secret` |
| Bob | `http://host.docker.internal:8644/v1` | `bob-secret` |
The model dropdown will show `alice` and `bob` as distinct models. You can assign models to Open WebUI users via the admin panel, giving each user their own isolated Hermes agent.
> [!-success] -success
> Custom Model Names
>
> The model name defaults to the profile name. To override it, set `API_SERVER_MODEL_NAME` in the profile's `.env`:
>
> ```bash
> hermes -p alice config set API_SERVER_MODEL_NAME "Alice's Agent"
> ```
## Linux Docker (no Docker Desktop)
On Linux without Docker Desktop, `host.docker.internal` doesn't resolve by default. Options:
```bash
# Option 1: Add host mapping
docker run --add-host=host.docker.internal:host-gateway ...
# Option 2: Use host networking
docker run --network=host -e OPENAI_API_BASE_URL=http://localhost:8642/v1 ...
# Option 3: Use Docker bridge IP
docker run -e OPENAI_API_BASE_URL=http://172.17.0.1:8642/v1 ...
```

117
raw/Agent/n8n 调用openclaw agents的工作流架构.md Normal file
View File

@@ -0,0 +1,117 @@
#n8n #openclaw #agents
## OpenClaw API Server 配置
OpenClaw 的 Gateway 可以提供 OpenAI 兼容的 [Fossies](https://fossies.org/linux/openclaw/docs/gateway/openai-http-api.md) Chat Completions 端点，**默认是关闭的**，需要在配置中手动开启。
### 第一步：开启端点
编辑 `~/.openclaw/openclaw.json`，添加：
json
```json
{
"gateway": {
"port": 18789,
"mode": "local",
"bind": "lan",
"auth": {
"mode": "token",
"token": "fb97035a1b62a4f29e5cb2f9ac131bd37f021a10823f66b0"
},
"tailscale": {
"mode": "off",
"resetOnExit": false
},
"remote": {
"url": "ws://192.168.3.189:18789"
},
"nodes": {
"denyCommands": [
"camera.snap",
"camera.clip",
"screen.record",
"contacts.add",
"calendar.add",
"reminders.add",
"sms.send"
]
},
"controlUi": {
"allowInsecureAuth": true
},
"http": {
"endpoints": {
"chatCompletions": {
"enabled": true
}
}
}
}
}
```
> `host: "0.0.0.0"` 是为了让 Docker 容器能访问，和 Hermes 同理。
然后重启 Gateway：
bash
```bash
openclaw gateway restart
```
验证：
bash
```bash
curl http://localhost:18789/v1/health
```
---
## 与 Hermes 的关键区别
|项目|Hermes|OpenClaw|
|---|---|---|
|默认端口|`8642`|**`18789`**|
|Agent 指定方式|`"model": "hermes-agent"`|**`"model": "openclaw:main"`**|
|默认是否开启|✅ 开启|❌ 需手动开启|
OpenClaw 通过 `model` 字段来指定 Agent ID，格式为 `"openclaw:<agentId>"`，例如 `"openclaw:main"` 或 `"openclaw:beta"`。 [OpenClaw AI](https://openclaw-ai.com/en/docs/gateway/openai-http-api/)
---
## 在 n8n 中调用 OpenClaw
json
```json
{
"model": "openclaw:main",
"messages": [
{"role": "user", "content": "{{ $json.input }}"}
]
}
```
| 字段 | 值 |
| ------------- | ------------------------------------------------ |
| URL | `http://192.168.3.189:18789/v1/chat/completions` |
| Authorization | `Bearer your-secret-key` |
---
## 最终架构总结
```
n8n (Docker)
│
├─ POST 192.168.3.189:8642 → Hermes Agent (port 8642)
│
└─ POST 192.168.3.189:18789 → OpenClaw Agent (port 18789)
```
两个都用同一个局域网 IP，只是端口不同，在 n8n 里分别建两个 HTTP Request 节点就可以了。你的 OpenClaw 现在是什么状态，已经安装好了吗？

152
raw/Agent/n8n调用hermes agents的工作流架构.md Normal file
View File

@@ -0,0 +1,152 @@
---
title: "n8n调用openclaw/hermes agents的工作流架构"
source: "https://claude.ai/chat/a18d1fa2-7e98-4f86-bac0-1167281eb151"
author:
published:
created: 2026-04-20
description: "Claude conversation with 8 messages"
tags:
- "clippings"
---
好消息！**Hermes Agent 内置了 OpenAI 兼容的 API Server**，完全不需要额外写任何代码，直接配置开启就行。
---
## 第一步：开启 Hermes API Server
Hermes 的 API Server 会将 hermes-agent 暴露为一个 OpenAI 兼容的 HTTP 端点，默认端口是 **8642**。 [GitHub](https://github.com/NousResearch/hermes-agent/blob/main/website/docs/user-guide/features/api-server.md)
bash
```bash
# 开启 API Server
hermes config set API_SERVER_ENABLED true
# 设置一个访问密钥（必须）
hermes config set API_SERVER_KEY your-secret-key
# 启动 Gateway（API Server 随之运行）
hermes gateway install # 安装为系统服务
hermes gateway start # 启动
```
验证是否正常运行：
bash
```bash
curl http://localhost:8642/v1/health
# 返回 {"status": "ok"} 即成功
```
```bash
weishen@WeideMac-mini ~ % hermes config set API_SERVER_ENABLED true
✓ Set API_SERVER_ENABLED = True in /Users/weishen/.hermes/config.yaml
weishen@WeideMac-mini ~ % nano /Users/weishen/.hermes/config.yaml
weishen@WeideMac-mini ~ % hermes config set API_SERVER_KEY 01KPN2YYSEV56BZQSQX9XGW6VH
✓ Set API_SERVER_KEY = 01KPN2YYSEV56BZQSQX9XGW6VH in /Users/weishen/.hermes/config.yaml
weishen@WeideMac-mini ~ % nano /Users/weishen/.hermes/config.yaml
weishen@WeideMac-mini ~ % hermes gateway restart
✓ Service restarted
weishen@WeideMac-mini ~ % curl http://localhost:8642/v1/health
{"status": "ok", "platform": "hermes-agent"}% weishen@WeideMac-mini ~ % curl http://localhost:8642/v1/chat/completions \
-H "Authorization: Bearer 01KPN2YYSEV56BZQSQX9XGW6VH" \
-H "Content-Type: application/json" \
-d '{"model": "hermes-agent", "messages": [{"role": "user", "content": "Hello!"}]}'
{"id": "chatcmpl-e1569aadb12b4e36aedd9198b29e1", "object": "chat.completion", "created": 1776677020, "model": "hermes-agent", "choices": [{"index": 0, "message": {"role": "assistant", "content": "Hello! How can I help today?"}, "finish_reason": "stop"}], "usage": {"prompt_tokens": 11458, "completion_tokens": 63, "total_tokens": 11521}}%
```
---
## 第二步：为每个 Agent 创建独立 Profile
你可以用 Profile 的方式为每个用户/角色创建独立的 Hermes 实例，每个 profile 跑在不同端口，配置独立的 API key。 [GitHub](https://github.com/NousResearch/hermes-agent/blob/main/website/docs/user-guide/features/api-server.md)
bash
```bash
# 创建三个专用 Agent（以任务分工为例）
hermes profile create agent-researcher
hermes profile create agent-writer
hermes profile create agent-coder
# 分别配置端口和 key
hermes -p agent-researcher config set API_SERVER_ENABLED true
hermes -p agent-researcher config set API_SERVER_PORT 8643
hermes -p agent-researcher config set API_SERVER_KEY key-researcher
hermes -p agent-writer config set API_SERVER_ENABLED true
hermes -p agent-writer config set API_SERVER_PORT 8644
hermes -p agent-writer config set API_SERVER_KEY key-writer
hermes -p agent-coder config set API_SERVER_ENABLED true
hermes -p agent-coder config set API_SERVER_PORT 8645
hermes -p agent-coder config set API_SERVER_KEY key-coder
# 分别启动三个 gateway
hermes -p agent-researcher gateway &
hermes -p agent-writer gateway &
hermes -p agent-coder gateway &
```
---
## 第三步：在 n8n 中调用
每个 Agent 都是标准的 OpenAI 格式接口，在 n8n 中用 **HTTP Request 节点**：
|字段|填写内容|
|---|---|
|Method|POST|
|URL|`http://localhost:8643/v1/chat/completions`|
|Header: Authorization|`Bearer key-researcher`|
|Header: Content-Type|`application/json`|
Body（JSON）：
json
```json
{
"model": "agent-researcher",
"messages": [
{
"role": "system",
"content": "你是一个专门负责网络调研的Agent，请搜索并总结信息"
},
{
"role": "user",
"content": "{{ $json.task }}"
}
]
}
```
---
## 多轮对话保持上下文（重要）
v0.7.0 起 API Server 支持通过 `X-Hermes-Session-Id` header 来保持会话连续性，让 chat-completions 客户端也能跨请求共享同一个 session。 [GitHub](https://github.com/mudrii/hermes-agent-docs)
在 n8n 的 HTTP Request 节点 Header 中加一行：
```
X-Hermes-Session-Id: my-workflow-session-001
```
这样同一个工作流里的多次调用会共享上下文，非常适合需要多步推理的任务链。
---
## 完整架构示意
```
n8n Workflow
│
├─ [HTTP Request] → localhost:8643 (agent-researcher) → 搜索/调研
│
├─ [HTTP Request] → localhost:8644 (agent-writer) → 内容生成
│
└─ [HTTP Request] → localhost:8645 (agent-coder) → 代码任务
```
这套方案完全原生支持，不需要任何额外中间件。你现在的 Hermes 是哪个版本？可以用 `hermes version` 确认一下，部分特性需要 v0.4.0+。

64
raw/Cloud & DevOps/SRE Weekly Issue 513.md Normal file
View File

@@ -0,0 +1,64 @@
---
title: "SRE Weekly Issue #513"
source: "https://sreweekly.com/sre-weekly-issue-513/"
author:
- "[[lex]]"
published:
created: 2026-04-20
description:
tags:
- "clippings"
---
[View on sreweekly.com](https://sreweekly.com/sre-weekly-issue-513/)
[Organizational Second Hit Syndrome](https://www.adaptivecapacitylabs.com/2026/03/07/organizational-second-hit-syndrome/)
A previously unpublished article by the late Dr. Richard Cook!
> Organizational Second Hit Syndrome is an incident-related phenomenon analogous to neurological second-impact-syndrome (SIS). It occurs when a major incident creates a vulnerable period during which a second incident generates strong, widespread, and sometimes destructive organizational reactions.
John Allspaw and Dr. Richard I. Cook — Adaptive Capacity Labs
[Mount Mayhem at Netflix: Scaling Containers on Modern CPUs](https://netflixtechblog.com/mount-mayhem-at-netflix-scaling-containers-on-modern-cpus-f3b09b68beac)
Over 20k mounts to run 100 containers! And NUMA issues too. This one really drives home the fact that SREs need to be cognizant of all layers of the stack.
Harshad Sane and Andrew Halaney — Netflix
[Cost Is a Distributed Systems Bug](https://dzone.com/articles/cost-is-a-distributed-systems-bug)
Cost explosion is a reliability problem. I love the idea of surfacing sudden cost increase as an alert that something is probably going wrong.
David Iyanu Jonathan — DZone
[Autoscaling Is Not Elasticity](https://dzone.com/articles/autoscaling-is-not-elasticity-1)
> Autoscaling is reactive, not resilient. Without caps, metrics, or overrides, it can worsen failures. True elasticity requires policy, testing, and bottleneck awareness.
Raise your hand if your system has ever autoscaled itself to death. ✋
David Iyanu Jonathan — DZone
[The On-Call Problem AI Can Actually Solve](https://www.runllm.com/blog/the-on-call-problem-ai-can-actually-solve)
> Heinrich Hartmann argues AI’s most valuable role in SRE isn’t autonomous remediation. It’s making sure on-call engineers have the context to fix incidents fast.
Peter Farago — RunLLM
[Quick thoughts on GitHub CTO’s post on availability](https://surfingcomplexity.blog/2026/03/12/quick-thoughts-on-github-ctos-post-on-availability/)
As usual, I enjoy reading Lorin’s analysis of GitHub’s writeup on their incidents just as much as the writeup itself, if not more. Saturation, a security mechanism causing an outage, and more.
Lorin Hochstein
[From vendors to vanguard: Airbnb’s hard-won lessons in observability ownership](https://medium.com/airbnb-engineering/from-vendors-to-vanguard-airbnbs-hard-won-lessons-in-observability-ownership-3811bf6c1ac3)
Airbnb made a big move, migrating to a new observability stack. They explain how they structured the project to deliver a big win as early as possible, building buy-in.
Callum Jones — Airbnb
[5 Ways That Resilience Can’t Be Automated](https://uptimelabs.io/articles/5-ways-that-resilience-cant-be-automated/)
Each one of these is like a pile of War Stories all gathered up into a tidy package of we can learn from.
Karan Nagarajagowda — Uptime Labs

122
raw/Home Office/n8n Docker 配置 Telegram 代理 Troubleshooting.md Normal file
View File

@@ -0,0 +1,122 @@
#n8n #docker #http-proxy #https-proxy #telegram #xray #v2ray
## 问题描述
n8n 运行在 Docker 容器内，宿主机已有代理（xray/v2ray 监听 `10808` 端口），但 n8n 的 Telegram 节点无法连接 `api.telegram.org`。
---
## 排查过程
### 1. 宿主机可以访问，容器不行
宿主机用 proxychains 可以正常访问 Telegram API：
```bash
proxychains4 curl https://api.telegram.org/bot<TOKEN>/getMe
# ✅ 返回 bot 信息
```
容器内用 Node.js fetch 测试：
```bash
node -e "fetch('https://api.telegram.org/...').then(r=>r.text()).then(console.log).catch(console.error)"
# ❌ ETIMEDOUT
```
### 2. 发现 docker-compose.yml 中代理地址错误
```yaml
# ❌ 错误：容器内的 127.0.0.1 是容器自身，不是宿主机
HTTP_PROXY: http://127.0.0.1:10808
HTTPS_PROXY: http://127.0.0.1:10808
```
### 3. 修正为 host.docker.internal
```yaml
# ✅ 正确：通过 host.docker.internal 访问宿主机
HTTP_PROXY: http://host.docker.internal:10808
HTTPS_PROXY: http://host.docker.internal:10808
```
`host.docker.internal` 能工作的前提是 `docker-compose.yml` 中已有：
```yaml
extra_hosts:
- "host.docker.internal:host-gateway"
```
### 4. 确认代理端口可达
在容器内验证连通性：
```bash
node -e "
const net = require('net');
const s = net.createConnection(10808, 'host.docker.internal', () => {
console.log('✅ 代理端口可达');
s.destroy();
});
s.on('error', e => console.log('❌ 失败:', e.message));
"
# ✅ 代理端口可达
```
宿主机确认代理监听地址：
```bash
ss -tlnp | grep 10808
# LISTEN *:10808 ← 监听 0.0.0.0，容器可以访问 ✅
```
### 5. Node.js 原生 fetch 不读代理环境变量
`node fetch` 不会自动使用 `HTTP_PROXY`/`HTTPS_PROXY`，所以容器内的测试命令显示 ETIMEDOUT 是**测试方法有误**，并非代理没生效。
**n8n 使用 axios**，axios 会自动读取代理环境变量，所以 n8n 节点内是正常工作的。
验证方法：直接在 n8n 里用 **HTTP Request 节点** 访问：
```
https://api.telegram.org/bot<TOKEN>/getMe
```
能返回 bot 信息即代理生效 ✅
---
## 最终解决方案
### docker-compose.yml 关键配置
```yaml
services:
n8n:
environment:
HTTP_PROXY: http://host.docker.internal:10808 # 指向宿主机代理
HTTPS_PROXY: http://host.docker.internal:10808
NO_PROXY: localhost,127.0.0.1 # 内网地址不走代理
extra_hosts:
- "host.docker.internal:host-gateway" # 必须！映射宿主机 IP
```
### 前提条件
|条件|检查命令|
|---|---|
|宿主机代理监听 `0.0.0.0`（非 `127.0.0.1`）|`ss -tlnp \| grep 10808`|
|docker-compose 有 `extra_hosts` 配置|查看 yml 文件|
### 重启生效
```bash
docker compose down && docker compose up -d
```
---
## 总结
|问题|原因|解决|
|---|---|---|
|代理不生效|`127.0.0.1` 在容器内指向容器本身|改为 `host.docker.internal`|
|测试误报 ETIMEDOUT|Node.js 原生 `fetch` 不读代理环境变量|用 n8n HTTP Request 节点直接测试|