Dify 的模型供应商页面弹出“凭据验证失败”时最常见的低效动作是连续改 Base URL、换模型名、重贴 API Key然后反复点保存。问题在于这些输入分别作用于不同层而页面只给出一个聚合结果。只要一次修改三个变量即使突然成功也很难知道真正修复了什么一旦环境变化故障还会回来。更可靠的方法是把“验证”改写成一组可以单独判定的命题Dify 的实际运行环境能否解析域名并完成 TLS请求是否抵达正确的 HTTP 资源凭据是否按目标服务要求送达最小模型调用是否满足接口契约。每个命题只需要一个小探针每个探针都保留退出码、HTTP 状态、响应摘要和时间。本文讲的是通用工程方法不代表某个具体服务已经提供文中提到的运维能力。先定义失败边界页面红字不是根因Dify 官方的 Model API Interface 把供应商级凭据校验写成validate_provider_credentials同时又为不同模型类型定义各自的调用接口。这一点很关键界面上的“验证失败”是某段校验代码抛出的结果不等于它天然知道根因更不等于所有模型能力都已经被测试。不同插件版本、供应商实现或可自定义模型配置完全可能选择不同的测试调用。因此排错记录的第一行不应写“Dify 连不上模型”而应写成可证伪的事实例如“容器内解析成功TLS 成功最终请求返回 401响应中没有 request_id”。这句话已经把 DNS、TCP、TLS 和路径不存在的大部分猜测排除在外。相反“保存失败”“接口不兼容”“网络有问题”都只是标签没有说明观察发生在哪一层。先建立四个边界。第一层是传输名称解析、连接、TLS 是否完成。第二层是 HTTP 入口方法、主机、版本前缀和资源路径是否组成了预期 URL。第三层是身份鉴权头是否存在、格式是否正确、凭据是否被目标服务接受。第四层是调用契约模型标识、请求字段、响应媒体类型和响应结构是否满足调用方预期。只有上一层有成功证据才进入下一层。这套边界还能纠正一个常见误会收到 401 或 404并不是“完全连不上”。服务器已经返回了 HTTP 响应名称解析、连接和通常意义上的 TLS 握手至少走到了能交换 HTTP 消息的位置。此时继续重启网络、反复改 DNS价值很低应该转向请求目标、鉴权头和响应体。反过来如果 curl 只给出名称解析或证书错误就还没有资格讨论模型名。建议在工单里固定五列stage、observation、evidence、excluded、next_probe。每完成一个探针只更新一行。这样团队讨论的是同一份证据而不是每个人凭经验猜一条原因。页面红字仍然保留但它只是证据之一不再承担“根因结论”的角色。现场操作还应有一条暂停规则当当前证据不能区分两个候选原因时不继续修改配置而是设计一个能把二者分开的探针。例如“可能是路径错误也可能是鉴权错误”时先观察未带凭据的已知资源与带凭据的目标资源分别返回什么而不是同时换 URL 和 Key。每个动作开始前写下预期结果若假设 A 成立会看到什么若假设 B 成立会看到什么。实际结果不属于任何预期时标记为“未知”重新定义问题不要强行把它塞进最接近的分类。这个纪律能避免排错过程变成试错日志也让后来者知道为什么执行某条命令。探针必须从 Dify 的实际运行环境发出自托管 Dify 常运行在容器或集群中。管理员在 Windows 宿主机执行 curl 成功只能证明宿主机的 DNS、证书库、代理变量和出口策略可用不能证明 API 容器或插件守护进程也走同一条路径。两个环境可能使用不同的 DNS 服务器、CA 证书、HTTP_PROXY、HTTPS_PROXY、NO_PROXY甚至不同的 IPv4/IPv6 路由。所以第一条原则是“从失败发生的进程附近发探针”。如果错误由插件进程产生优先进入对应容器或使用同网络命名空间的临时诊断容器如果无法进入至少分别记录宿主机与应用容器的结果明确它们不是同一个证据。不要为了方便把本地电脑上的成功截图当成生产容器的连通性证明。同环境并不意味着必须安装一整套调试工具。最小集合通常包括能够解析名称的命令、能够显示 TLS 和 HTTP 细节的 curl、当前代理环境变量、系统时间、CA 证书位置。先记录版本和命令输出再执行请求。系统时间错误会影响证书有效期判断代理变量会改变实际目的地容器镜像里的旧 CA 包也可能让宿主机成功而容器失败。还要区分“探针改变环境”和“探针观察环境”。临时关闭证书校验、删除代理变量、改 hosts都会让证据失真。可以把这些动作作为后续的单变量对照实验但不能把绕过后的成功写成原配置已修复。尤其不要把-k或--insecure当成正式解决方案它只跳过证书验证既没有修复信任链也可能掩盖代理劫持或主机名不匹配。建议为每次探针生成一个运行卡执行位置、容器名或实例标识、镜像版本、UTC 时间、代理变量是否设置、命令、退出码、HTTP 状态、响应头摘要、响应体错误码。敏感字段只记录“存在、长度区间、指纹后四位”等不可逆摘要不记录完整值。这样下一位排错者可以复现而不必获取真实密钥。当无法直接进入失败容器时可以做三点对照宿主机、同网络中的诊断容器、Dify 应用实例。三者使用同一个只读探针目标、相同超时和相同请求结构。若只有宿主机成功优先比较容器 DNS、代理和 CA若诊断容器成功而应用实例失败继续比较进程环境、运行用户和插件网络若三者都失败才把范围扩大到公共出口或上游。对照表里必须保留失败结果不能只贴成功命令。很多“偶尔好了”的案例其实是探针落到了不同实例、不同出口或不同协议族实例标识和解析地址能把这种漂移暴露出来。第一段探针先证明 DNS、连接与 TLS第一段不发送模型请求只回答“能否安全到达服务入口”。curl 的退出码与 HTTP 状态码是两套概念名称解析失败、连接拒绝、连接超时、证书校验失败会产生 curl 或 libcurl 层的错误只有收到 HTTP 响应后才有 2xx、4xx、5xx 状态。把两者塞进同一列会让“没有 HTTP 响应”和“服务明确拒绝请求”看起来一样。可以先执行只取响应头或短超时的入口请求并打开详细信息。记录解析到的地址、连接目标、TLS 协议、证书主机名校验结果和总耗时。此处不要求业务端点返回成功即使入口返回 404只要确认响应来自预期主机也证明传输层已经走通。不要根据一个网关生成的通用 HTML 404 就认定业务路径正确还需要在下一段核对资源。DNS 失败时依次比较容器内解析结果、宿主机解析结果、DNS 配置和搜索域不要立刻换公共 DNS。连接失败时记录目标 IP 与端口检查出口策略、服务监听和代理。TLS 失败时记录证书链、颁发者、有效期、主机名与系统时间。证书问题的正确修复通常是补齐受信 CA、修正服务证书或修正访问主机名而不是永久关闭验证。代理环境尤其容易制造假象。显式代理可能返回自己的 407、403 或证书透明代理可能替换证书NO_PROXY写法不匹配时内网域名会被错误送到外部代理。探针卡应同时记录“命令中是否显式指定代理”和“进程环境是否隐式设置代理”。只有这样宿主机成功、容器失败的差异才可解释。这一段的通过条件应写得保守在目标运行环境中名称解析得到预期网络范围连接在预算内建立TLS 证书验证通过并收到来自目标入口或其受控网关的 HTTP 响应。它不证明鉴权正确也不证明任何模型可用。通过后冻结 DNS、代理和证书配置进入 HTTP 路径探针避免再改已经有证据通过的层。为了让 TLS 结果可复核证据中至少记录访问主机名、证书主题或 SAN 摘要、颁发者、有效期、验证结果和系统时间而不是只写“证书正常”。若链路经过企业代理还应记录最终看到的证书由谁签发但不要据此自动判定代理合规或不合规。IPv4 成功、IPv6 失败时也应分开记录因为同一个域名的两类地址可能走不同出口。对连接超时设置短而明确的预算并重复少量次数观察是否稳定不要让一个长达数分钟的默认超时阻塞整个排查也不要用高频循环给目标服务制造额外压力。第二段探针把最终 URL 写出来再查 404Base URL 最容易出现的问题不是“格式不漂亮”而是调用方与使用者对拼接职责理解不同。有的配置项期望服务根地址有的期望版本前缀有的代码会自动追加资源路径。若用户填了完整端点而插件再次追加/v1/chat/completions最终 URL 就会重复若双方都认为对方会追加/v1最终路径又会缺段。因此不要只截配置输入框要从网络日志、反向代理访问日志或可控的测试服务中取得“最终方法 最终 URL”。在没有最终 URL 的情况下讨论 Base URL等于只看源代码的一半。取得 URL 后把它拆成 scheme、host、port、base path、version prefix、resource path 六个字段逐项比对并标出哪一段由用户填写、哪一段由插件追加。本文涉及向量引擎时只采用事实白名单中已确认的三个地址服务根地址 https://api.vectorengine.cnOpenAI 兼容接口前缀 https://api.vectorengine.cn/v1Chat Completions 接口 https://api.vectorengine.cn/v1/chat/completions。它们分别表示入口、前缀和具体资源。究竟在 Dify 某个配置项中填写哪一级必须以实际插件的拼接行为和一次最终请求证据为准不能仅凭字段名推断。收到 404 时先保存响应的Content-Type、服务器标识、请求 ID 和短错误体。JSON 404 可能来自目标 APIHTML 404 可能来自前置网关、Web 站点或错误虚拟主机相同状态码并不代表相同责任层。再用相同主机分别探测已知入口和目标资源判断是整个主机错误、版本前缀错误还是单个资源不存在。不要用无限枚举路径的方式“撞接口”。应从产品文档、插件实现或服务端路由定义获得候选路径再做有限对照。每次只变更一段例如只比较是否包含/v1其他请求头和请求体保持不变。若一次同时改 host、前缀和模型名结果无法归因。路径通过的标准是最终 URL 与约定一致响应来自预期服务且不再出现资源不存在类错误它仍不证明凭据或模型调用通过。还要识别“同一个 404 的不同生成者”。反向代理、API 网关、应用路由和上游服务都可能返回 404。比较响应头、媒体类型、错误对象形状和 request ID可以判断响应在哪一层生成若有服务端访问日志再用时间、路径与请求 ID 做关联。没有关联证据时不要因为页面上出现某个品牌词就断定请求到达了业务处理器。若代理会重写路径记录重写前后的值用户填写的 Base URL 可能正确但代理规则把资源前缀剥掉最终仍会失败。修复应落在首次改变预期路径的那一层而不是在客户端继续叠加补丁。第三段探针401 先查身份链不要先换模型HTTP 401 表示请求缺少有效认证凭据。对排错而言它至少说明请求已经抵达某个会执行身份判断的 HTTP 服务。此时模型名通常不是第一变量因为很多服务会在解析业务请求前先校验身份。先检查“凭据是否存在、是否进入正确进程、是否组成正确请求头、是否被中间层删除、是否由目标服务接收”。密钥从配置页到上游请求可能经过数据库加密存储、任务队列、插件进程、SDK 和反向代理。不要打印完整密钥来证明每一跳相同。可以在受控环境中对原始值计算不可逆指纹只比较指纹也可以记录长度、前缀类型和末四位。日志中Authorization: Bearer ***只能证明日志做了遮蔽不能证明实际请求头存在所以还需要请求侧或服务侧的结构化字段。使用 curl 复现时通过环境变量注入不把凭据写进命令历史、脚本仓库或截图。下面的探针仅展示通用写法MODEL_ID必须换成经目标服务资料确认的标识不能从界面显示名猜测。curl.exe--silent--show-error --fail-with-body\--connect-timeout5--max-time30\-HAuthorization: Bearer${VECTORENGINE_API_KEY}\-HContent-Type: application/json\-d{\model\:\${MODEL_ID}\,\messages\:[{\role\:\user\,\content\:\ping\}]}\${CHAT_COMPLETIONS_URL}排查 401 时还要检查时钟、代理和虚拟主机。某些鉴权机制依赖时间某些代理会移除 Authorization 头某些网关会按 Host 路由到不同租户。本文不假设具体服务采用哪种机制只要求把实际链路记录清楚。不要凭一次 401 推断账号被封、额度耗尽或模型无权限这些结论需要目标服务的明确错误表示或原始资料支持。鉴权层的通过条件不是“页面变绿”而是使用同一运行环境、同一入口和同一凭据结构请求不再返回身份无效类错误并获得可归因到后续层的响应。通过后冻结凭据和请求头只改变模型调用所需字段。这样即使第四段失败也不会重新把已经通过的身份链拖回猜测池。第四段探针最小模型调用才检验调用契约传输、路径和鉴权都通过后才进入模型调用。这里要证明的不是“这个域名上有某种 AI 服务”而是目标资源能接受当前模型标识与请求结构并返回调用方可解析的响应。模型列表请求成功也不能替代聊天请求成功因为两者可能是不同资源、不同权限和不同响应结构。最小请求要尽量短但不能删掉契约必需字段。对聊天类调用保留model、最小messages、正确的Content-Type关闭非必要的流式、工具调用、结构化输出和扩展参数。这样失败时变量更少。若最小非流式请求通过再逐项恢复 Dify 实际发送的参数直到找到第一个导致失败的差异。响应证据至少包括 HTTP 状态、媒体类型、错误对象中的稳定字段、请求 ID、首个非敏感响应片段和耗时。不要只保留界面翻译后的错误文字。官方 OpenAI Python SDK 的错误设计也体现了这一边界连接问题与带状态码的 API 错误是不同异常失败响应可关联 request ID。兼容服务未必实现相同字段所以记录时允许为空但不能伪造。如果返回 400应先读错误体判断是 JSON 无效、字段类型不对、缺少必填字段还是参数不支持如果返回模型不存在或无访问权应核对实际发送的model值和目标服务资料如果返回 200 但 Dify 仍失败则检查响应媒体类型、JSON 字段、流式事件格式和插件解析日志。不要把所有 400 都归为“模型名错”也不要把所有 200 都当成完整成功。第四段通过后再回到 Dify 复现。此时探针与 Dify 请求之间只应剩下可列举的差异执行进程、SDK 版本、请求头、请求体字段、超时、代理和流式模式。逐项对齐而不是重新从 DNS 开始。这样“curl 成功、Dify 失败”不再是一句矛盾描述而是一组可以继续比较的输入差异。比较两个请求时先做归一化删除时间戳、随机边界和请求 ID对 JSON 对象按键排序把敏感字符串替换为类型与长度标记再比较字段集合、类型和值域。仅看格式化后的文本差异常会被字段顺序和动态值淹没。优先关注 Dify 多出的默认参数、布尔值与字符串的类型差异、空值是否被发送、流式开关以及消息内容结构。响应也做同样处理状态相同但媒体类型不同、错误字段嵌套位置不同、成功体缺少调用方期待的字段都可能让插件失败。把最小成功请求逐字段扩展到 Dify 请求比从完整失败请求不断删字段更容易保持因果清晰。用一张矩阵区分退出码、状态码和错误体排错效率取决于证据是否落在正确列。推荐把每次运行记录成一行探针编号、执行环境、curl 退出码、HTTP 状态、Content-Type、错误码、request ID、耗时、结论、下一步。curl 退出码回答“传输是否完成”HTTP 状态回答“服务器如何处理请求”错误体回答“服务给出的具体原因”。三者不能互相替代。例如退出码非零且没有 HTTP 状态优先处理解析、连接、TLS 或本地超时退出码为零且状态 401转入身份链状态 404核对最终 URL 和响应来源状态 400检查请求结构和模型字段状态 429 或 5xx先读取服务端语义再决定是否重试。这里的分类是通用排查起点不是对任何具体服务错误策略的承诺。矩阵还应保留“首次失败时间”和“最近成功基线”。没有成功基线时很难区分新故障和从未正确配置。基线不需要保存正文只保存接口版本、请求结构哈希、模型标识、状态、媒体类型、响应结构摘要和耗时区间。升级插件、代理或上游协议后运行同一组基线差异会直接暴露。对超时要记录阶段而不只是一个总数字。连接超时说明连接没有按预算建立首字节超时说明连接建立后迟迟没有响应流式读取中断说明已经有响应但传输未完成Dify 页面等待超时还可能来自队列或插件层。一个“30 秒超时”无法说明哪个计时器先到期也无法指导应该修改哪一层。矩阵的结论必须使用证据语言。写“排除 DNS因为容器内解析成功且连接到预期地址”不要写“网络正常”写“最终 URL 重复/v1修正后 404 消失并进入 401”不要写“Base URL 已修复”。精确结论能保留尚未验证的部分避免团队把局部成功误当成全链路通过。矩阵中应允许unknown而不是只有通过和失败。比如连接被中途关闭但没有服务端日志既不能证明上游主动拒绝也不能证明本地网络故障请求返回网关 HTML 502也不能直接证明模型服务宕机。此时结论写“响应生成层未确认”下一步是用 request ID、网关访问日志或另一个受控入口定位。未知状态不是工作质量差而是对证据边界诚实。只有在补充证据后才更新分类并保留旧结论和更新时间避免复盘时看不到推理过程。证据要可共享但不能泄露凭据和正文一份可共享的排错包应包含环境、请求结构、响应结构和时间线却不应包含完整 API Key、Cookie、用户正文、文件内容或未经评估的业务数据。最危险的做法是直接导出完整 HAR、复制全部容器环境变量或粘贴curl -v原文因为这些材料常包含 Authorization、Cookie、查询参数和请求体。脱敏应在采集脚本中完成而不是先把原始材料发到群里再撤回。对 Authorization 只保留方案名和不可逆指纹对 Cookie 整段删除对请求体保留字段名、类型、数组长度和内容哈希对响应体保留稳定错误字段与短摘要对 URL 查询参数按白名单保留。脱敏后再人工复核一次特别检查截图边缘、终端历史和折叠区域。Chrome DevTools Network 面板可以记录请求、保留跨页面日志并重放 XHR但浏览器证据只代表浏览器路径。它适合观察 Dify 前端调用后端的请求不一定能看到后端再调用上游的完整内容。前端请求成功只能证明浏览器到 Dify上游模型请求仍要从服务端日志、插件日志或同运行环境探针取得。给外部支持人员的最小包可以包含Dify 版本与部署方式、失败时间和时区、插件或供应商标识、最终 URL 的主机与路径、HTTP 方法、状态码、媒体类型、错误码、request ID、脱敏后的请求字段表、同环境 curl 对照结果。不要附带真实密钥也不要为了“方便复现”创建权限过大的长期密钥。排错完成后原始证据也要按团队规则处理。本文不假设向量引擎或其他服务具备任何日志保留、数据存储或隐私承诺这些产品事实未在白名单中确认。通用建议是明确证据所有者、访问范围、保存期限和销毁动作并在复盘中记录哪些材料曾经包含敏感值。回到 Dify只改一个变量并保留前后请求四段探针完成后再回 Dify 配置页。此时不要凭记忆重填而是把已经通过的值逐项映射回配置哪个字段提供服务入口插件是否追加版本前缀凭据从哪里注入模型标识如何传入验证动作实际调用哪个资源。Dify 官方 Model Specs 区分 Provider、模型实体、模型类型和配置方法这正说明相邻输入框并不属于同一个责任层。每次保存前先建立变更记录原值的脱敏摘要、新值的脱敏摘要、变更理由、预期影响层、回滚值。保存后立刻采集一次实际请求与上一轮对比最终 URL、请求头结构和请求体字段。若差异超出计划范围例如只改 Base URL 却连模型字段也变化应先解释插件行为再继续排错。若 Dify 仍失败而同环境 curl 已通过建立“请求差异表”。第一列是 curl第二列是 Dify逐项比较 DNS 结果、代理、证书、方法、URL、Host、Authorization 方案、Content-Type、请求体字段、模型标识、流式开关、超时和响应解析。不要直接得出“Dify 有 bug”先找到一个可复现的最小差异再查对应插件实现或提交问题。版本信息不可省略。Dify 主程序、插件、容器镜像和反向代理都可能独立升级。相同界面在不同版本中不一定触发相同请求。记录准确版本能让官方仓库的代码和问题记录真正可用也能防止团队把旧教程中的字段行为套到当前环境。升级前后的探针结果应放在同一张矩阵里比较。一旦找到修复不要删除失败证据。保留修复前最后一次失败和修复后第一次成功二者只允许存在计划中的单变量差异。这样的“成对证据”比一张绿色界面截图更有价值它能说明因果关系也能直接转成回归测试输入。修复顺序按依赖走回归闸门按证据建修复顺序应遵循依赖先传输再路径再鉴权最后调用契约。上层依赖下层DNS 未通时修改模型名没有意义路径仍是 404 时轮换密钥也无法证明新密钥有效。每一层修复后先重跑本层探针再重跑前面已通过的短探针确认没有引入回归然后才进入下一层。不要对确定性配置错误设置自动重试。错误路径、无效凭据、缺少字段通常不会靠等待自行恢复盲目重试只会放大日志和请求量。连接瞬断、明确的暂时性服务错误是否可重试也要依据目标服务语义、幂等性和统一重试预算决定。本文不为任何具体接口规定重试次数或速率因为白名单没有相应事实。把四段探针纳入发布闸门时可以分成快速检查和完整检查。快速检查不发送业务正文只验证入口、TLS、已知资源和脱敏的最小调用完整检查在受控环境验证插件实际请求、超时和响应解析。闸门输出必须是结构化结果至少包含版本、时间、各阶段状态、失败证据和是否允许继续。成功标准也要分层。供应商凭据校验通过不代表所有模型类型通过最小非流式聊天通过不代表流式、工具调用或长上下文通过单次调用通过不代表并发、配额、SLA 或长期可用性。后面这些能力必须有独立资料和测试不能从一次绿色状态外推。复盘时记录三件事为什么原监控没有快速指出失败层为什么操作人员会一次修改多个变量哪些探针可以自动化。真正的改进不是多写一篇“正确配置值”而是让下一次失败在几分钟内落到正确证据列并让每个修复都有成对的前后结果。回归用例至少覆盖六种结果名称无法解析、证书不受信、资源路径不存在、凭据无效、请求字段无效、最小调用成功。前五种用例不一定要攻击真实上游可以在受控测试服务中返回稳定响应验证诊断器能否把错误放进正确列。成功用例只使用非敏感短输入并断言状态、媒体类型和最小响应结构。再增加一个“HTTP 成功但响应结构错误”的反例防止闸门只看 200。用例输出不保存密钥和正文失败时提供阶段、证据摘要与修复指引插件或代理升级后先跑这组测试再允许业务流量验证。成功基线也要有失效条件。只要 Dify 主版本、模型插件版本、代理规则、证书链、目标资源路径或请求结构发生变化旧基线就不能继续代表当前链路应重新生成并由责任人复核。密钥轮换本身不要求保存新密钥只需更新凭据指纹与验证时间。若基线长期没有执行不应把最后一次绿色结果当成今天仍然可用在变更窗口开始前先运行短探针能把环境漂移与本次变更影响分开。基线的价值不是承诺永远成功而是为每次变化提供明确的比较起点。最终交付一张表、一组探针、一对证据Dify 模型验证失败并不可怕可怕的是把它当成一个不可拆分的红灯。只要把链路改写成四个命题排错就有稳定顺序从实际运行环境证明 DNS、连接和 TLS写出最终 URL 核对 HTTP 入口沿凭据链验证身份用最小模型调用检查请求与响应契约。每一步都只改变一个变量。最终交付不需要堆满原始日志。保留一张证据矩阵、一组可重复的脱敏探针、修复前后的一对结果再附版本和环境说明即可。矩阵告诉团队当前失败在哪一层探针让别人复现成对证据说明修复为什么有效。页面截图可以作为补充但不能替代这些结构化材料。在配置真实服务时还应坚持事实边界。已知地址可以准确记录未知的价格、模型清单、并发、延迟、SLA、日志、隐私、合规、SDK 和企业能力不能从一次请求推断。关于向量引擎的进一步配置资料可在 https://178.nz/dn 查看任何具体能力仍应以可追溯资料和实际验证为准。最后给出一份执行清单确认失败发生的进程记录版本、时区和代理运行传输探针记录最终 URL运行无敏感正文的鉴权与最小调用分开保存退出码、状态码和错误体回到 Dify 单变量复现生成修复前后证据把探针纳入升级回归。完成这九项“验证失败”就从模糊提示变成了可定位、可复现、可回归的工程事件。参考资料Dify Docs, Model API Interfacehttps://docs.dify.ai/en/develop-plugin/features-and-specs/plugin-types/model-schema.mdDify Docs, Model Specshttps://docs.dify.ai/en/develop-plugin/features-and-specs/plugin-types/model-designing-rules.mdDify Documentation Indexhttps://docs.dify.ai/llms.txtDify 官方 GitHub 仓库https://github.com/langgenius/difyOpenAI 官方 Python SDKhttps://github.com/openai/openai-pythonOpenAI OpenAPI 规范仓库https://github.com/openai/openai-openapiRFC 9110: HTTP Semanticshttps://www.rfc-editor.org/rfc/rfc9110.htmlcurl, libcurl Error Codeshttps://curl.se/libcurl/c/libcurl-errors.htmlChrome for Developers, Network features reference 原始 Markdownhttps://github.com/GoogleChrome/developer.chrome.com/blob/main/site/en/docs/devtools/network/reference/index.mdMDN, 401 Unauthorizedhttps://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/401MDN, 404 Not Foundhttps://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/404