文章目录

对支持工程师来说，“代理不能用”这句话，差不多就像病人对医生说“里面某处疼”。方向是清楚了，但没有化验结果和症状，根本没法下诊断。这篇指南会教你收集一整套数据，把模糊的抱怨变成目标明确、一次就能给出答案的具体问题。

引言：为什么“不能用”根本无法诊断

想象两个发往 Proxeon 支持团队的请求。第一个：“买了代理，什么都用不了，快帮忙”。第二个：“标识为 PX-48213 的代理在莫斯科时间（UTC+3）14:32 通过 HTTP 请求 api.example.com 时返回连接错误，但同一个代理访问另一个网站正常，不用代理直接用也正常，curl 输出附上”。第一个请求会引发五六封补充信息的往来邮件，每封都要等上好几个小时。第二个一封回复就能解决。

差别不在礼貌，也不在运气。差别在数据。工程师看不到你的屏幕，不知道你的操作系统，没有原始参数就没法复现你的请求。他手上只有你邮件里的文字。如果这些文字里没有事实，他首先要做的就是索要事实。这就是那条把简单问题拖上好几天的邮件链。

读者最终会得到什么

看完这篇指南，你就能在 15-20 分钟内收集出一套诊断数据包，包含首次回复即可解决问题所需的一切。你会有一个现成的脚本，能把技术数据汇总到一个文本文件；有一个可以直接复制的工单模板；还能清楚知道在联系支持前该做哪些检查。

本指南适合谁

本指南面向中级代理用户：能打开终端或命令行、知道什么是 URL、至少配置过一次代理的人。高级用户能在这里找到现成的诊断脚本和故障隔离对照表。新手我们也会详细解释每个术语。

需要提前了解什么

理解三件事就够了。代理是你网络请求经过的中介。目标地址是你访问的网站或服务。客户端是发出代理请求的程序（浏览器、爬虫、脚本）。其余内容我们边做边讲。

需要多长时间

第一次按指南操作并配置脚本，大约需要 30 分钟。之后用现成模板收集诊断信息，每次只需 10-15 分钟。这和来回补充信息好几天完全没法比。

建议：把这篇指南和脚本加入书签。代理问题很少出现，一旦出现，很难重新回忆起整个流程。手边有现成的检查清单能省不少心。

前期准备：工具和权限

收集数据之前，先确认你有基础工具。它们全都免费，而且大多数系统已经自带。

必需工具

  • curl — 发送网络请求的命令行工具。这是我们复现问题的主力工具。macOS 和大多数 Linux 发行版都已预装。Windows 10 和 11 也自带。
  • 终端或命令行 — 输入命令的窗口。Windows 上是 PowerShell 或命令提示符（cmd），macOS 和 Linux 上是 Terminal。
  • 文本编辑器 — 记事本、TextEdit 或任何能查看收集到的文件并删除机密信息的工具。
  • Proxeon 给你的代理数据 — 标识、地址、端口、登录名和密码。这些都在你的个人中心里。

检查 curl 是否存在

打开终端，做个简单检查。

  1. Windows 上按 Win 键，输入 PowerShell 并打开应用。
  2. macOS 上按 Cmd+空格打开 Spotlight，输入 Terminal 并回车。
  3. Linux 上通过应用菜单或 Ctrl+Alt+T 打开终端。
  4. 输入命令 
    curl --version
    并回车。

如果你看到类似“curl 8.x.x”并列出支持的协议，工具就准备好了。如果系统提示找不到命令，就安装 curl：Windows 更新到最新版本，Linux 通过你发行版的包管理器安装。

✅ 检查：命令 

curl --version
输出了版本号和协议列表，包括 http 和 https。说明一切准备就绪。

需要准备哪些 Proxeon 数据

登录 proxeon.net 的 Proxeon 个人中心，打开你的代理卡片。把以下字段抄写或复制到单独文件：代理标识、主机（地址）、端口、类型（HTTP、HTTPS 或 SOCKS5）、登录名和密码。这些数据在构造复现命令时会用到。

⚠️ 注意：代理的登录名和密码是机密数据。我们会在本地使用它们，但绝不插入到支持工单里。下面有专门一节讲如何在发送前安全清理日志。

基础概念：客户端—代理—服务器边界

要理解哪些数据重要，需要先想象请求的路径。它经过三个区段，问题可能出现在任何一处。

一条链上的三个环节

当你通过代理访问网站时，请求是这样走的：你的客户端把请求发给代理服务器，代理把它转发给目标服务器，拿到响应后返回给你。三个环节，两个边界。搞清楚卡在哪个边界上，诊断就完成了一半。

  • 客户端—代理边界。如果请求连代理都没到，问题在你这边：代理地址错误、端口关闭、企业过滤器、客户端设置错误。
  • 代理—服务器边界。如果代理收到了请求，但无法到达目标网站，问题在代理和目标之间：网站不可用、拒绝连接或返回错误。

诊断的任务就是确定哪个边界断了。Proxeon 支持工程师从你的输出里一眼就能看出请求停在哪里，这会大大缩小原因范围。

为什么精确时间如此重要

代理基础设施会保留日志。要在日志里找到你的具体请求，工程师需要事件的精确时间并注明时区。“今天早上”在日志里是搜不到的。“莫斯科时间 14:32，UTC+3”几秒钟就能搜到。你的表述和日志记录之间的时差，是事件根本找不到的常见原因。

建议：永远明确标注时区。“UTC+3”或“МСК”这种格式不会有歧义。如果你在其他时区，标注自己的即可——服务器会自行换算。

第 1 步：收集最小数据集合

本阶段目标：固定五个事实，没有它们任何工单都不完整。这是基础，其他一切都建立在这之上。

五个必填事实

  1. 代理标识。Proxeon 个人中心里的准确名称或编号，例如 PX-48213。不是“昨天买的那个代理”，而是具体标识。如果你有多个代理的套餐，要指明是哪一个。
  2. 带时区的精确时间。问题具体何时发生。格式：日期、时间、时区。例如：2026年3月12日，14:32，UTC+3。如果问题反复出现，列出多个时间点。
  3. 目标地址。你访问的完整 URL 或主机。例如：https://api.example.com/v2/data。不是“某个网站”，而是准确地址。
  4. 你具体做了什么。用一两句话描述操作。“从自己的脚本发送 GET 请求”或“用配置了代理的浏览器打开网站”。背景有助于理解请求的性质。
  5. 你期望什么、得到了什么。期望 200 状态码和数据，得到的是连接错误。期望页面加载，得到的是无限加载。期望与现实的差距就是问题的本质。

⚠️ 注意：不要用情绪替代具体信息。“什么都慢，简直糟糕”不包含技术信息。“响应要 40 秒，而不是平时的 2 秒”才有信息量。

如何正确记录时间

如果问题正在发生，看一眼时钟立刻记下时间。如果发生在过去，根据应用日志或浏览器历史恢复时间。时间戳越精确，越容易在服务器端找到记录。

✅ 检查：你记录了五个事实。大声读一遍。如果一个看不到你屏幕的人能明白发生了什么、在哪里、何时发生，最小集合就算收集完成。

第 2 步：用一条 curl 命令复现问题

本阶段目标：把问题归结为一条命令，工程师能在脑中或实际操作中重复它，并获得详细的技术输出。

浏览器和复杂脚本会做几十个隐藏操作。在它们里面隔离问题很难。curl 只发一个请求，并展示它的每一步。这是理想的复现工具。

通过 Proxeon 代理的基础命令

用你的数据组装命令。大致形式如下：

curl -v -x http://登录名:密码@主机:端口 https://目标地址

解释一下参数。-v 开启详细模式（verbose）：curl 会逐行显示整个连接过程。-x 指定请求经过的代理。后面是带认证的代理地址。最后是目标地址。

代入值后的示例（数据为虚构）：

curl -v -x http://user123:secretpass@proxy.proxeon.net:8080 https://api.example.com/v2/data

加入时间测量并写入文件

为了让输出尽可能有信息量，我们扩展命令。-w 参数会在末尾加上时间统计概要。

curl -v -x http://user123:secretpass@proxy.proxeon.net:8080 -w "最终状态码: %{http_code}, 总时间: %{time_total}s" https://api.example.com/v2/data

现在输出最末尾会显示最终 HTTP 状态码和请求总时间。这是诊断速度的关键数字。

建议：如果问题是慢而不是报错，通过 

-w "dns: %{time_namelookup} connect: %{time_connect} start: %{time_starttransfer} total: %{time_total}"
添加详细时间。这能看出时间耗在哪一步。

用于 SOCKS5 代理

如果你的代理是 SOCKS5 类型，把地址里的协议换掉：

curl -v -x socks5://user123:secretpass@proxy.proxeon.net:1080 https://api.example.com/v2/data

⚠️ 注意：命令包含你的真实登录名和密码。在自己的终端里执行它，但不要把带机密信息的命令复制到邮件里。工单里登录名和密码要替换为占位符——第 5 步会讲。

执行步骤

  1. 打开终端。
  2. 粘贴组装好的命令，代入你自己的真实数据。
  3. 按回车，等它结束。
  4. 从第一行到最后一行选中整个输出，复制到文本文件。

✅ 检查：你得到了多行输出，能看到以“*”、“>”和“<”开头的行。只要有输出，复现就成功了，即使请求以错误结束——错误也是有价值的信息。

第 3 步：逐行阅读输出，找到问题边界

本阶段目标：学会看懂 curl 输出，并判断请求停在哪个环节。具体错误码的解读我们这里不重复——Proxeon 知识库里有专门文章，需要时在工单里附上链接即可。

输出中的三类行

curl 的详细输出用前缀区分，很容易辨认。

  • 星号（*）行 — curl 自身关于连接过程的服务消息：域名解析、与代理建立连接、加密握手。这是内部细节。
  • 右箭头（>）行 — 你的客户端发送的内容。请求头、方法、路径。
  • 左箭头（<）行 — 对方回复你的内容。响应码、服务器头。

客户端—代理边界在哪里

输出开头 curl 会说明正在与代理建立连接。你会看到类似“Connected to proxy.proxeon.net port 8080”的行。如果没有这一行，取而代之的是连接错误，说明请求没到代理。问题在客户端—代理边界：可能端口关闭、地址错误或本地过滤器拦截。

如果有连接代理的行，但接下来是认证错误，说明代理可达，但没接受你的登录名和密码。这也是客户端—代理边界，不过是认证层面。

代理—服务器边界在哪里

成功连上代理后，curl 会显示通过代理与目标服务器建立连接。如果这里出错，说明代理收到了请求，但无法到达目标。问题在代理—服务器边界：目标网站不可用、拒绝连接或响应缓慢。

如果你看到左箭头响应行，比如“< HTTP/1.1 200”或其他状态码，说明整条链都工作了，你拿到了响应。接下来就是响应内容的问题，而不是代理工作的问题。

工程师关心的关键行

  1. 连接代理的行 — 确认第一个环节正常。
  2. 代理认证相关的行 — 显示凭据是否被接受。
  3. 加密握手（TLS）的行 — 对 HTTPS 目标很重要。
  4. 第一个左箭头响应行 — 整条链的最终判决。
  5. 来自 -w 参数的带状态码和时间的最终概要。

建议：如果不确定，不要自己根据错误码下诊断。你的任务是附上完整输出。Proxeon 工程师读得更准确。错误码的完整解读在知识库的专门文章里——想深入了解可以引用它。

✅ 检查：你能用手指指出请求从哪一行开始坏掉，并说出它在哪个边界——客户端-代理还是代理-服务器。如果能，这一步就通过了。

第 4 步：联系前执行检查

本阶段目标：用排除法在你写支持工单之前就缩小原因范围。每项检查都能排除一整类问题。

原则很简单：一次只改一个参数，观察行为是否变化。这是隔离故障的经典工程方法。

四项关键检查

  1. 换一个目标网站。用同一个代理重复同样的请求，但指向另一个地址。选一个公认稳定的公开网站。如果它能通，而你的目标不通，问题就与目标网站或它对代理的态度有关，而不是代理本身。
  2. 换一个协议。如果用的是 HTTP，试试 HTTPS 目标，反之亦然。有时问题只在一个协议上出现，这是重要信号。
  3. 换一个代理。如果你有第二个 Proxeon 代理，用它重复请求。如果第二个能通而第一个不通——问题在具体那个代理。如果两个表现相同——问题更系统化。
  4. 直连。不用代理，直接对目标发请求。去掉 -x 参数。如果直连也访问不了，问题根本不在代理，而在目标网站或你的网络。

直连检查的命令

curl -v https://api.example.com/v2/data

同样的命令，但去掉代理部分。把结果与通过代理的请求对比。

表格：每项检查排除了什么

下面是各项检查结果的解读方式。

  • 另一个网站能通，你的不通。排除代理整体故障。指向具体目标与代理交互的特殊性。
  • 另一个协议能通，你的不通。排除完全不可达。把问题定位到具体协议或端口层面。
  • 另一个代理能通，你的不通。排除你这边和网络的问题。指向具体代理。
  • 直连也不通。排除代理的责任。问题在目标网站或你的网络。
  • 直连通，通过代理不通。确认问题就出在与代理的配合上，这正是支持能帮上忙的地方。

建议：这四项检查的结果是工单最有价值的部分。它们省了工程师一半的工作，因为你已经排除了多余因素。务必在邮件里逐条列出。

⚠️ 注意：这些代理只能用于合法用途：测试自己的服务、在规则范围内收集公开数据、对接 API。检查不用于违反网站规则或法律的行为。

✅ 检查：四项检查的结果你都有了，能用一句话说出它们共同排除了什么。例如：“直连和另一个代理都能通，说明问题出在具体代理 PX-48213 访问这个目标时”。

第 5 步：收集你这边的情况数据

本阶段目标：描述问题发生的环境。一半的疑难案例都能用客户端或本地网络的特点解释。

需要说明的环境信息

  1. 操作系统及版本。Windows 11、macOS 15、Ubuntu 24.04。精确版本有助于复现条件。
  2. 客户端及版本。你通过什么使用代理：浏览器及版本、爬虫或库的名称和版本、curl 版本。不同客户端对代理的处理方式不同。
  3. 代理配置方式。配置在系统里、浏览器里、代码中传递，还是设置环境变量。这影响代理具体如何生效。
  4. 是否有企业或本地过滤器。你是否在企业网络中、是否有带网络防火墙的杀毒软件、是否有本地防火墙。这类过滤器可能在到达代理之前就拦截或阻断连接。
  5. 互联网连接类型。家庭宽带、移动网络、办公网络。有时运营商会影响可达性。

如何查看客户端版本

curl 用已经熟悉的命令 

curl --version
浏览器在菜单里打开“关于”页面。代码中的库，在项目依赖文件里查看其版本。

检查企业过滤器

如果你在企业网络中并怀疑有过滤器，这很容易验证。直接对代理发请求、不带目标，看看连接是否建立。如果连代理端口的直连都通不过，而从另一个网络能通过，很可能存在针对出站连接的企业过滤器。

建议：企业网络通常只放行 80 和 443 端口。如果你的代理在非标准端口上，向你的网络管理员确认该端口是否对外开放。这是常见且容易解决的原因。

✅ 检查：你有一份填好的五项环境信息。工程师读完就知道在什么条件下复现问题。

第 6 步：用一个脚本自动收集诊断信息

本阶段目标：把所有技术信息汇总到一个文本文件，不用手写。脚本做的手工做过的事，但一次运行完成。

macOS 和 Linux 脚本

创建文件 diag.sh，内容如下。把变量值替换成你自己的。

#!/bin/bash
PROXY="http://登录名:密码@主机:端口"
TARGET="https://目标地址"
ALT="https://稳定网站"
OUT="diag_result.txt"
echo "=== 日期和时间 ===" > $OUT
date >> $OUT
echo "=== curl 版本 ===" >> $OUT
curl --version >> $OUT 2>&1
echo "=== 通过代理请求目标 ===" >> $OUT
curl -v -x $PROXY -w "code:%{http_code} total:%{time_total}s" $TARGET >> $OUT 2>&1
echo "=== 通过代理请求替代网站 ===" >> $OUT
curl -v -x $PROXY -w "code:%{http_code} total:%{time_total}s" $ALT >> $OUT 2>&1
echo "=== 直连目标（不用代理） ===" >> $OUT
curl -v -w "code:%{http_code} total:%{time_total}s" $TARGET >> $OUT 2>&1
echo "完成。文件：$OUT"

如何运行脚本

  1. 保存为 diag.sh。
  2. 把 PROXY、TARGET 和 ALT 变量填入你的值。
  3. 在终端里进入文件所在目录。
  4. 用 
    chmod +x diag.sh
    让文件可执行。
  5. 用 
    ./diag.sh
    运行它。
  6. 结束后打开 diag_result.txt 文件。

Windows 脚本（PowerShell）

创建 diag.ps1 文件，逻辑类似。

$Proxy = "http://登录名:密码@主机:端口"
$Target = "https://目标地址"
$Alt = "https://稳定网站"
$Out = "diag_result.txt"
"=== 日期和时间 ===" | Out-File $Out
Get-Date | Out-File $Out -Append
"=== curl 版本 ===" | Out-File $Out -Append
curl --version 2>&1 | Out-File $Out -Append
"=== 通过代理请求目标 ===" | Out-File $Out -Append
curl -v -x $Proxy -w "code:%{http_code} total:%{time_total}s" $Target 2>&1 | Out-File $Out -Append
"=== 通过代理请求替代网站 ===" | Out-File $Out -Append
curl -v -x $Proxy $Alt 2>&1 | Out-File $Out -Append
"=== 直连请求 ===" | Out-File $Out -Append
curl -v $Target 2>&1 | Out-File $Out -Append

在 PowerShell 里用 

.\diag.ps1
运行它，然后打开生成的文件。

⚠️ 注意：diag_result.txt 文件里以明文形式包含你的登录名和密码，因为它们写在 PROXY 变量里。发给支持前务必按第 7 步的说明清理它。

建议：保留变量为空的脚本，只在运行前填入值。这样就不会不小心把带机密信息的文件分享出去。

✅ 检查：diag_result.txt 已创建，包含几个块：curl 版本、通过代理对两个网站的请求、直连请求。这就是完整的技术诊断数据包。

第 7 步：发送前安全清理日志

本阶段目标：从收集的数据中删除所有机密内容，同时保留其诊断价值。带密码的日志绝对不能发送，任何情况都不行。

必须删掉的内容

  • 代理密码。输出中它可能出现在连接行里。找出来并替换。
  • 登录名（如果与支付数据关联）。通常登录名可以保留，但如果它是敏感组合的一部分，也替换掉。
  • 授权令牌。如果请求头里有 Authorization、Bearer 令牌、API 密钥、会话 cookie ——全部删掉。
  • 个人数据。任何姓名、地址、电话，如果它们偶然出现在请求体或响应体里。

用什么替换

不要整行删除——那样会丢失结构。把机密内容替换为清晰的占位符，尽可能保留长度和格式。替换示例：

  • 密码替换为 [密码已隐藏]。
  • 登录名替换为 [登录名已隐藏]。
  • 令牌替换为 [令牌已隐藏]。

这样工程师能看到这里原本是令牌，但看不到它的值。结构保留了，安全性也保住了。

清理步骤

  1. 用文本编辑器打开 diag_result.txt。
  2. 用搜索（Ctrl+F）查找你的密码，把所有出现处替换为占位符。
  3. 如果决定隐藏登录名，对登录名同样处理。
  4. 检查 Authorization、Cookie、api-key 等请求头行。把值替换为占位符。
  5. 用新名字保存文件，例如 diag_clean.txt，以免和原文件混淆。

⚠️ 注意：发送前仔细检查两遍。密码可能不仅出现在命令里，也出现在 curl 的输出行里。遗漏的机密就是泄露，可能导致你的代理被入侵。

建议：把原文件 diag_result.txt 留在本地，只发清理后的副本。如果工程师要求补充信息，你手边有完整数据。

✅ 检查：打开清理后的文件，搜索你的密码。零结果说明清理成功。输出结构仍然保留。

第 8 步：填写现成的工单模板

本阶段目标：把所有内容汇总成一封邮件，工程师读完就能立刻理解问题。下面是可直接复制的模板。

Proxeon 支持工单模板

主题: 代理 [标识] 访问 [目标] 时出现问题

1. 代理标识: [例如 PX-48213]
2. 代理类型: [HTTP / HTTPS / SOCKS5]
3. 问题时间: [2026.03.12, 14:32, UTC+3]
4. 目标地址: [https://api.example.com/v2/data]
5. 做了什么: [从 curl 发送 GET 请求]
6. 期望: [200 状态码和数据]
7. 实际: [连接错误 / 响应缓慢 / 错误码]

检查结果:
- 通过此代理访问其他网站: [正常 / 不正常]
- 不用代理直连: [正常 / 不正常]
- 用其他代理访问同一目标: [正常 / 不正常 / 没有第二个代理]

环境:
- 操作系统: [Windows 11]
- 客户端: [curl 8.6.0]
- 代理配置方式: [curl 的 -x 参数]
- 企业过滤器: [无 / 有，放行 80 和 443 端口]

诊断输出（登录名和密码已隐藏）见附件 diag_clean.txt。

简要结论: 根据我的检查，问题在 [客户端-代理 / 代理-服务器] 边界，因为 [直连正常，通过代理不通]。

如何正确填写

  1. 把模板复制到邮件或工单正文。
  2. 把方括号里的每个字段替换成你的数据。
  3. 附上清理后的 diag_clean.txt 文件。
  4. 从头读一遍邮件：外人看得明白吗。
  5. 发送。

建议：最后的“简要结论”行最有用。你在其中基于检查结果自己提出假设。即使假设不准确，也能让工程师看到你的思路，节省时间。

✅ 检查：邮件里没有任何方括号字段——全部填好了。清理后的文件已附上。有带假设的简要结论。工单可以发送了。

结果检查：工单就绪清单

发送前过一遍短清单。它保证你没有遗漏任何东西。

  • 标明了精确的代理标识，而不是描述。
  • 有带明确时区的事件时间。
  • 标明了完整目标地址。
  • 描述了做了什么、期望什么、得到了什么。
  • 附上了详细模式下的完整 curl 输出。
  • 执行并描述了至少两项排除性检查。
  • 标明了操作系统、客户端及其版本。
  • 日志中密码和所有令牌已删除。
  • 诊断文件已附上且命名清晰。
  • 有带假设的简要结论。

如果所有条目都打勾了，你的工单就属于首次回复即可解决的那类。工程师无需再问任何细节——他手上有完整的画面。

✅ 检查：清单十项全部完成。这就是成功的标志：工单自给自足。

常见错误及解决办法

我们来分析收集诊断信息时的常见问题和应对方法。

问题 1：curl 立刻报错，连不上代理

原因：代理地址格式错误或协议拼写错误（http 写成了 socks5，或反之）。

解决：在 Proxeon 个人中心核对代理类型，填上正确的协议。确认端口正确并用冒号分隔。

问题 2：代理认证错误

原因：登录名或密码错误，或密码中的特殊字符未转义。

解决：重新核对凭据。如果密码里有 @、:、/ 等字符，它们可能破坏字符串。这种情况下用单独参数 

--proxy-user 登录名:密码
传递认证，而不是插入 URL。

问题 3：脚本在 Windows 上无法运行

原因：PowerShell 执行策略阻止本地脚本。

解决：以管理员身份启动 PowerShell，用进程级策略把执行权限设为 RemoteSigned。收集完数据后恢复原策略。

问题 4：输出里没有细节，只有最终行

原因：忘了 -v 参数，它负责开启详细模式。

解决：在 curl 后立刻加上 -v。正是它逐行显示连接过程，没有它诊断毫无用处。

问题 5：密码不小心留在了发送的文件里

原因：清理不仔细，密码出现在输出行里，而不只是在命令里。

解决：立刻在 Proxeon 个人中心修改代理密码。今后发送前务必在清理后的文件里搜索密码。

问题 6：curl 里问题不出现，但浏览器里有

原因：浏览器添加了请求头、cookie，或使用了不同的代理配置方式。

解决：在工单里如实说明 curl 中问题不复现，但浏览器中有。附上浏览器名称、版本及其代理配置方式。这本身就是诊断信息。

问题 7：日志里的时间与你的对不上

原因：你用了本地时间但没标时区，而服务器按 UTC 运行。

解决：永远明确标注时区。如果不确定，把两个时间点都附上：你的本地时间和对应的 UTC 时间。

进阶功能：高级诊断

如果基础数据不够，这里有几个更深入分析的工具。适合高级用户。

针对速度问题的详细时间

当代理能用但很慢时，重要的是弄清楚时间耗在哪一步。扩展的 -w 参数会给出细分。

curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" -x http://登录名:密码@主机:端口 https://目标

这些数字显示解析域名、建立连接、加密和收到第一个字节各花了多久。如果 ttfb 大，延迟在目标那边。如果 connect 大，问题在到代理的网络。

问题的复现性

如果问题时有时无，收集一串请求，展示哪些通过哪些不通过。几个请求的简单循环并记录状态码就能给出统计。稳定与否——对支持来说是重要事实。

一次检查多个目标

列出三四个地址，用一组请求跑一遍。这样能立刻看出问题是某个目标特有的还是普遍的。

建议：只有在基础诊断不够时才附上高级数据。没有结构的过量信息和信息不足一样有害。从最小集合开始，按工程师的要求深入。

FAQ：收集诊断信息的常见问题

必须用 curl 吗？

不必须，但 curl 是对工程师最通用、最好理解的工具。它的输出在所有系统上一致。如果你通过代码中的库工作，也附上它的输出，但 curl 检查作为基准仍然有价值。

如果问题已经过去且不再复现怎么办？

把所有记得的都记下来：大概时间、目标、错误性质。附上那段时间你应用的日志。即使数据不完整，只要有精确时间，就能在服务器上找到记录。

如果描述里错误已经很明显，还需要附日志吗？

需要。你觉得显而易见的事，需要用事实确认。日志能消除猜测，给出准确答案而不是假设。

可以发送登录名和密码让支持自己检查吗？

不可以。机密信息不通过通信传递。Proxeon 支持可以凭标识访问你的账户，无需密码。仅凭标识就足以在服务器端检查。

如果一切收集妥当，多久能收到回复？

完整的工单能把解决时间大幅缩短，因为它消除了补充信息的循环。具体时限取决于支持的负载，但你肯定能避免好几轮往来邮件。

如果 curl 显示成功，但应用还是不能用怎么办？

这是有价值的事实：问题不在代理本身，而在应用如何使用它。在工单里说明这一点，附上应用中的代理配置及其版本。

如果目标是公开的，还需要标明地址吗？

需要，务必标明。代理的行为可能取决于具体目标。没有地址，工程师就无法复现你的具体情况。

怎么知道我的端口对不对，还是需要别的？

端口写在个人中心的代理卡片上。不同代理类型用不同端口。对照个人中心，不要随便填端口。

可以自动清理日志中的机密信息吗？

关于作者

Roman Melnikov

Roman Melnikov

Technical Writer and System Administrator

工作经验： Technical writer and DevOps engineer with 9 years of experience. Created over 50 detailed guides on system configuration and administration. His instructions helped thousands of professionals successfully solve technical tasks. Popular author on Habr and YouTube.
教育背景： Bauman Moscow State Technical University. Information Systems and Technologies
专业领域：
Technical Documentation DevOps System Administration Linux Docker and Kubernetes CI/CD Infrastructure Automation Cloud Technologies System Monitoring Bash and Python Scripting

分享文章：