后端CLI【免费下载链接】check-if-email-existsCheck if an email address exists without sending any email, written in Rust. Comes with a ⚙️ HTTP backend.项目地址https://gitcode.com/gh_mirrors/ch/check-if-email-exists点击查看免费下载导读Reacher v0.10 是一次面向生产环境可扩展性的大版本升级它在原有/v0/*API 之上引入了全新的/v1/*端点支持限流throttle与并发控制并将批量验证从基于数据库轮询的旧实现迁移到 RabbitMQ 队列架构。本文以官方迁移文档为骨架结合本仓库源码backend/src/config.rs、backend/src/throttle.rs、backend/src/http/v1逐项讲解新增端点行为、环境变量新旧对照表、批量验证架构变迁并给出可落地的迁移实操步骤。读完本文你将能够把运行在 v0.7 的自托管 Reacher 后端平滑升级到 v0.10 配置体系并正确启用/v1端点。v0.10 引入了哪些新端点v0.10 的核心变化是新增了一组/v1/*端点与旧版/v0/*端点并存端点作用新增行为POST /v1/check_email单次邮箱验证尊重配置中设置的 throttle限流与并发设置POST /v1/bulk创建批量验证任务将邮箱列表发布到 RabbitMQ 队列GET /v1/bulk/{job_id}查询批量任务的进度与状态从 Postgres 聚合统计结果GET /v1/bulk/{job_id}/results拉取批量任务的完整结果支持 CSV见 backend/src/http/v1/bulk/get_results其中/v1/check_email的实现细节可以从 backend/src/http/v1/check_email/post.rs 中看到请求到达后首先执行throttle_manager.check_throttle()backend/src/throttle.rs一旦超过限流配额立即返回429 TOO_MANY_REQUESTS并携带被命中的限流档位与等待时长随后根据config.worker.enable决定是在当前进程内直接执行验证handle_without_worker还是通过 RabbitMQ RPC 模式把任务投递给 worker 并等待回包handle_with_worker使用correlation_id与临时reply_queue实现请求-响应匹配。关键结论/v0/check_email的行为完全不变迁移文档特别强调了一个容易踩坑的事实/v0/check_email端点在 API 和行为上均不改变。即使你在新版 Reacher Configuration 中配置了 throttle 与并发设置/v0/check_email也不会应用它们——它仍然在收到请求后立即执行验证。这一点在源码中得到双重印证在 backend/src/http/v0/check_email/post.rs 的http_handler中直接调用check_email(...)并立即返回全程没有任何 throttle 检查在 backend/backend_config.toml 的[throttle]小节注释中明确写道these throttle configurations only apply to /v1/* endpoints, and not to the previous /v0/check_email endpoint. The latter endpoint always executes the verification immediately这些 throttle 配置只作用于 /v1/* 端点旧端点始终立即执行验证。因此若你需要限流保护必须改用/v1/check_email保持调用/v0/check_email不会获得任何限流收益。迁移到 v0.10 时请务必将客户端从POST /v0/check_email切换到POST /v1/check_email。环境变量重命名对照表迁移核心v0.10 引入了全新的 Reacher Configuration见 docs/self-hosting/reacher-configuration-v0.10.md配置体系从散落的单下划线环境变量切换为RCH__前缀 双下划线分隔符的层级命名规范。官方迁移文档给出的新旧对照如下旧环境变量名新环境变量名说明RCH_HTTP_HOSTRCH__HTTP_HOSTHTTP 服务器绑定的主机名PORTRCH__HTTP_PORTHTTP 服务器绑定的端口通常由云平台注入RCH_SENTRY_DSNRCH__SENTRY_DSN设置后错误报告将发送到该 Sentry DSNRCH_HEADER_SECRETRCH__HEADER_SECRET设置后所有 HTTP 请求必须携带x-reacher-secret请求头用于保护后端免受公开恶意请求RCH_FROM_EMAILRCH__FROM_EMAILSMTP 流程MAIL FROM:阶段使用的邮箱可被每个请求的from_email字段覆盖RCH_HELLO_NAMERCH__HELLO_NAMESMTP 流程EHLO阶段使用的名称可被每个请求的hello_name字段覆盖RCH_SMTP_TIMEOUTRCH__SMTP_TIMEOUT每条 SMTP 连接的超时时间RCH_WEBDRIVER_ADDRRCH__WEBDRIVER_ADDR设置后使用无头浏览器访问密码找回页验证 Yahoo 与 Hotmail/Outlook 邮箱推荐使用支持并行请求的chromedriver例如http://localhost:9515批量验证相关RCH_ENABLE_BULKRCH__WORKER__ENABLE是否启用批量验证 workerDATABASE_URLRCH__WORKER__POSTGRES__DB_URL批量验证的数据库连接串用于存储结果与任务队列RCH_DATABASE_MAX_CONNECTIONS已移除旧的数据库连接池大小配置RCH_MINIMUM_TASK_CONCURRENCY已移除旧的并发任务下限低于该值则抓取更多任务RCH_MAXIMUM_CONCURRENT_TASK_FETCH已移除旧的单次抓取任务数量上限双下划线分隔符的底层机制新命名规范中的双下划线__不是随意的约定它直接对应配置加载代码的分层解析逻辑。在 backend/src/config.rs 中let cfg Config::builder() .add_source(config::File::with_name(backend_config)) .add_source(config::Environment::with_prefix(RCH).separator(__));Environment::with_prefix(RCH).separator(__)意味着RCH__HTTP_PORT会被解析为 TOML 结构中的http_port字段RCH__WORKER__POSTGRES__DB_URL会被解析为worker.postgres.db_url嵌套结构RCH__THROTTLE__MAX_REQUESTS_PER_MINUTE对应throttle.max_requests_per_minute。这也解释了为什么被移除的三个旧变量RCH_DATABASE_MAX_CONNECTIONS、RCH_MINIMUM_TASK_CONCURRENCY、RCH_MAXIMUM_CONCURRENT_TASK_FETCH在新架构中不再有对应位置——它们属于旧版数据库轮询任务队列sqlxmq的实现细节在 backend/src/http/v0/bulk/mod.rs 中仍能看到它们以默认值 10 / 20 被读取的痕迹而新架构已完全交给 RabbitMQ 与 Postgres 连接池管理。迁移实操Docker 环境变量示例v0.10 配置文件的完整形态可参考仓库自带的 backend/backend_config.toml每个字段都标注了对应的环境变量名。使用 Docker 运行 v0.10 后端时通过-e传入新命名规范的环境变量例如docker run -d \ -e RCH__HTTP_HOST0.0.0.0 \ -e RCH__HTTP_PORT8080 \ -e RCH__HELLO_NAMEmail.example.com \ -e RCH__FROM_EMAILhelloexample.com \ -e RCH__HEADER_SECRETmy-secret \ -e RCH__WEBDRIVER_ADDRhttp://localhost:9515 \ -p 8080:8080 \ reacherhq/backend:latest对照迁移你需要做的改动是将RCH_HTTP_HOST、RCH_HEADER_SECRET、RCH_FROM_EMAIL等旧变量全部替换为RCH__双下划线新名称若之前依赖云平台注入的PORT需改为显式传递RCH__HTTP_PORT若启用了批量验证用RCH__WORKER__ENABLEtrue替代RCH_ENABLE_BULKtrue并用RCH__WORKER__POSTGRES__DB_URL替代DATABASE_URL删除已废弃的RCH_DATABASE_MAX_CONNECTIONS、RCH_MINIMUM_TASK_CONCURRENCY、RCH_MAXIMUM_CONCURRENT_TASK_FETCH。迁移文档同时指出新配置体系中/v1/check_email会遵守[throttle]小节的限流设置backend/backend_config.toml推荐至少配置每分钟与每日上限默认建议值 60 次/分钟、10000 次/天避免源 IP 被邮箱服务商封禁。批量验证架构演进从数据库轮询到 RabbitMQ 队列迁移文档明确指出/v0/bulk端点已被弃用取而代之的是基于 RabbitMQ 的队列系统。旧版/v0/bulk的实现在 backend/src/http/v0/bulk 中它使用sqlxmq基于 Postgres 表做任务队列见 backend/src/http/v0/bulk/mod.rs 的create_job_registry通过RCH_MINIMUM_TASK_CONCURRENCY/RCH_MAXIMUM_CONCURRENT_TASK_FETCH控制任务抓取节奏这也正是那几个环境变量被移除的根源——整个队列机制被替换掉了。新版/v1/bulk的流程对应 backend/src/http/v1/bulk/post.rsPOST /v1/bulk接收{ input: [aexample.com, ...], webhook: {...} }先在 Postgres 的v1_bulk_job表插入一条任务记录记录total_records拿到job_id逐个邮箱构建CheckEmailTask以低优先级priority 1批量发布到 RabbitMQ 的check_email队列每批 10 个并发发布立即返回{ job_id: N }worker 消费队列执行验证结果写入v1_task_result表GET /v1/bulk/{job_id}backend/src/http/v1/bulk/get_progress.rs通过 SQL 聚合is_reachable的 safe / risky / invalid / unknown 计数返回任务状态Running或Completed与进度GET /v1/bulk/{job_id}/resultsbackend/src/http/v1/bulk/get_results拉取完整结果支持 CSV 导出backend/src/http/v1/bulk/get_results/csv_helper.rs。需要特别注意的是/v1/bulk端点必须在 worker 模式下才能使用。backend/src/http/v1/bulk/mod.rs 的with_worker_db过滤器会检查两点worker.enable必须为 true且必须配置了 Postgres 存储否则返回503 SERVICE_UNAVAILABLE。同时 backend/src/config.rs 在配置加载阶段就强制校验启用 worker 模式时必须配置 Postgres 数据库否则直接报错启动失败。启用 worker 模式的最小配置对应 backend/backend_config.toml[worker] enable true [worker.rabbitmq] url amqp://guest:guestlocalhost:5672 concurrency 5 [storage.postgres] db_url postgresql://localhost/reacherdb数据库结构由仓库中的迁移脚本创建详见 backend/migrations其中20240929230957_v1_worker_results.up.sql即/v1worker 结果表结构。RabbitMQ 的本地编排可参考 rabbitmq/docker-compose.yaml更完整的水平扩展架构说明见 docs/self-hosting/scaling-for-production。迁移自检清单完成从 v0.7 到 v0.10 的迁移后请逐项核对所有环境变量已切换到RCH__双下划线命名对照上文重命名表已删除三个废弃变量RCH_DATABASE_MAX_CONNECTIONS、RCH_MINIMUM_TASK_CONCURRENCY、RCH_MAXIMUM_CONCURRENT_TASK_FETCH单次验证客户端已从POST /v0/check_email切换到POST /v1/check_email以获得 throttle 限流保护需要限流时已在配置的[throttle]小节设置至少每分钟/每日上限批量验证已从/v0/bulk迁移到/v1/bulk并确保worker.enable true且配置了 Postgres 存储与 RabbitMQ 连接保留x-reacher-secret请求头逻辑若设置了RCH__HEADER_SECRET所有请求必须携带该头。由于/v0/check_email的 API 与行为完全向后兼容迁移过程可以渐进进行先升级后端并验证/v0/check_email仍正常再切换到/v1/check_email最后迁移批量验证链路从而将升级风险降到最低。赞分享后端CLI【免费下载链接】check-if-email-existsCheck if an email address exists without sending any email, written in Rust. Comes with a ⚙️ HTTP backend.项目地址https://gitcode.com/gh_mirrors/ch/check-if-email-exists点击查看免费下载相关推荐marimo 的 Model Context ProtocolMCP完整指南用 MCP Server 对外暴露 AI 工具、用 MCP Client 接入外部服务器marimo 的 Model Context ProtocolMCP完整指南用 MCP Server 对外暴露 AI 工具、用 MCP Client 接入后端CLI如何在 LibreChat Helm Chart 启用 Langfuse Fanout Gateway 并配置镜像、中心鉴权 Secret 与 Redis如何在 LibreChat Helm Chart 启用 Langfuse Fanout Gateway 并配置镜像、中心鉴权 Secret 与 Redis 本文后端CLIReachercheck-if-email-existsv0.7 Docker 环境变量完全配置指南Reachercheck if email existsv0.7 Docker 环境变量完全配置指南 本文以 Reachercheck if email后端CLI上一篇Claude Context 基础用法实战用 Milvus 语义搜索把整个代码库变成 Agent 上下文下一篇内存优化终极指南让Zettlr轻盈如飞的实用技巧创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考