在 VPS 上自托管 BTCPay Server

NVMe 上的修剪模式比特币节点，开放 80/443/8333/9735 端口，Prime 年付折合每月 $9.60 起。免 KYC，仅限加密货币结算，今天就把收款收进自己的钱包。

拥有通道，而不是租用通道

用手续费省多少来论证自托管 BTCPay，是最站不住脚的理由——真正有分量的理由是钱包自主权（custody）。第三方支付处理商可以冻结你的结算页面、扣留滚动准备金，甚至要求你提交买家的身份材料；而自己的节点自己开具账单，结算直接落进你的钱包，你和区块链之间不再蹲着一个对手方。支付通道由此从“按月订阅”升级为“自有资产”。

从机制上讲，BTCPay Server 是一个免费的自托管（self-custodial）支付处理系统：账单由你的节点所监视的地址生成，每笔结算都由节点对照区块链自行验证，而不是轻信某个 API 的说法（项目文档详细说明了这套架构——BTCPay Server documentation）。收款应用、众筹页面和 Greenfield API 都挂在同一份经过自行验证的余额之上，于是信任问题从“一家公司是否偿付得起”转移到了“你的备份是否足够自律”。

托管方案的选择也属于同一设计逻辑：如果 BTCPay 的意义在于把中间人赶出支付环节，那么一台需要你提交护照才能开通的服务器，等于在基础设施层面把中间人请了回来。在本站注册只需要令牌（token）或邮箱加 12 位密码，账单仅支持加密货币、覆盖十九种币，全程不交换任何 KYC 文件——最小资料下单指南解释了这意味着什么、又不意味着什么，而购买指南则逐步演示下单流程。

这里还有一层采购上的对称性值得注意：你的托管接受哪些币，你的顾客就能用哪些币付款。同一套账本——BTC、XMR、各条网络上的 USDT，以及十九种币中的其余——既结算基础设施账单，也承接店铺营收，对账面从两套支付体系缩减为一套，把最后一家刷卡收单机构从组织架构图上彻底划掉。

经典的错误是：支付处理环节自托管了，钱包自主权却只做了一半——助记词和应用程序存在同一块卷上，恢复流程从未演练过，也没有离线副本。BTCPay 替你免除了第三方，但免不了你对私钥的义务。把这次部署当作一个“碰巧长着网页界面的钱包自主权项目”来对待，后面几节的规格问题就变成了简单的算术，而不是关乎存亡的争论。

规格的下限由节点决定，而不是结算页面

每个 BTCPay 配置讨论帖里最反直觉的一点是：网页结算本身几乎不消耗资源，真正决定整个下限的是它背后的比特币节点。同步期间吃 CPU、索引计算期间吃内存的是区块验证，而不是账单渲染——所以要为一台“顺便提供结算服务的节点”来配机器，绝不能反过来；你的订单量再小，也影响不了这笔算术。

本站的实际下限是 Prime——4 vCPU、8 GB DDR5、160 GB NVMe，牌价 $12，年付折合每月 $9.60——足以带动一个修剪模式节点加网页结算，还能给一个小型店铺留出余量。以 $9.60/月（年付折算，牌价 $12）的 Prime 作为基线，等 Lightning 流量来了再升级；当路由真正成为日常业务时，Titan（牌价 $24，年付折合 $19.20，8 vCPU 和 32 GB ECC）才是从容的档位。两档都印在套餐一览表里。

为什么数字偏向这个方向：初始区块下载期间，节点要验证从创世区块以来的每一个区块——这是处理器密集型的验证工作，同时压在 NVMe 的写入通道上；同步完成后，即便账单川流不息，节点也只在个位数百分比的低 CPU 上打盹。而结算路径本身，每笔订单不过一小把请求。每个套餐都配备本地 NVMe，正是它把首次下载从几天压缩到几小时——所以在磁盘上，存储类别比存储容量更重要。

有一条超越 BTCPay 的配置经验值得带走：把“沉睡基线”和“同步峰值”分开测量。节点一生大部分时间在空闲，在同步、重建索引和崩溃后重索引时猛扑；店铺一生大部分时间在空闲，在促销活动时猛扑。按猛扑配置而不是按打盹配置，是这门手艺的全部——而两次猛扑很少落在同一个小时里，这正是同机部署（co-location）尚可商榷的原因。

错误示范：按账单量配置——每天二十笔订单听起来微不足道——于是买了一小块象征性的资源，然后纳闷为什么链同步要吞掉一整周、同步没完成时结算页面频频超时。节点才是那个从不睡觉的租客；为它配置好，结算页面就是白坐的顺风车。接下来几节按同样的顺序讨论磁盘、端口和 Lightning 的决策。

修剪模式：第一天就必须做对的唯一磁盘决策

运行一个完整验证的节点并不需要几 TB 空间——修剪模式（pruning）保持验证完整性，只丢弃你永远不会再次对外提供的古老区块数据。磁盘问题的实质不是链长到了多大，而是你的用途需要多少近期数据；答案只设定一次，以 MB 为单位，必须在第一次同步开始之前定下。

机制如下：Bitcoin Core 的 -prune=N 上限把区块存储限制在 N MB 以内，而 UTXO 集和索引保持完整——Core 代码库中的修剪文档定义了这一行为及其下限（Bitcoin Core pruning doc — doc/pruning.md）。BTCPay 的 Docker 部署通过环境变量而非手改配置文件来暴露这项设置，受支持的路线是 btcpayserver-docker 代码库（btcpayserver-docker），其中的 btcpay-setup.sh 会在每次改动后重新生成整套服务。

在本地 NVMe 上，修剪模式的首次下载以小时计，而不是以天计——Prime 的 160 GB NVMe 装下一个修剪节点绰绰有余，只要目标保持克制，Core 的 80 GB 也装得下。到了独立服务器（dedicated）上，Monolith 的 4×2 TB 则是归档级别的天地：完整保留全量区块，供真正需要它们的用途使用，背后还有 25 Gbps 端口和 L3/L7 清洗系统站岗。

修剪目标要跟着工作负载选，而不是跟着焦虑选：只需要当前余额和近期历史的结算页面，在远小于完整归档的规模下就活得好好的；而区块浏览器或数据分析爱好确实需要全部数据。多数“修剪后悔症”底下埋着的错误，是为项目从未声明的雄心做配置——先想清楚你究竟要跑哪些查询，MB 数字就会像一张收据一样自然得出。

典型的失误是：为了“保留选项”先不修剪地启动，同步中途 NVMe 被填满，清理之后不得不从头再下载一遍。先定目标——大多数纯结算部署从不复供旧区块——让磁盘预算跟随这个裁决。这一次同步中的耐心，换来的是之后每一张账单的可验证性。

端口与 TLS：三个开口，一个域名

一台 BTCPay 服务器的网络暴露面比新手想象的小得多：80 和 443 服务结算页面，8333 接收入站节点对等连接，9735 只在启用 Lightning 时才需要。其余一切——尤其是钱包 RPC——都留在回环地址上。相比仪表盘驱动下层层叠叠的端口开口，这份克制让部署更平静、也更安全。

首次运行之前，先把一个域名指向服务器：Docker 部署会针对该主机名自动申请并续期证书，A 记录在这里至关重要——Let's Encrypt 的速率限制容得下一次部署，但容不下对着配错的 DNS 每小时重试（限制说明——Let's Encrypt rate limits）。把记录一次配对，TLS 在服务器的一生里就成了不存在的事件，在你睡觉时自己完成续期。

入站开放 8333 端口，是你的节点向网络贡献对等节点、更早得知新区块的方式；关着它也能用，但你只是听众，而不是参与者。安装完成后用 ss -tlnp 审计监听面——这个套接字工具的手册页解释了每一列的含义（ss(8) manual）——并确认除了这三个端口之外没有任何东西面向公网。

每次改动服务栈之后都要重做这项审计，而不只是做一次：一次升级、一个插件，或某次调试留下的、绑定在 0.0.0.0 上的监听进程，都会比它的作者活得更久。每周把监听面与预期的三端口基线比对一次，配置漂移就从“一次发现”变成“一次告警”——让防火墙保持诚实的那个习惯，同样让一台钱包宿主机保持诚实。

经典错误：为了集成方便而把节点的 RPC 端口暴露出去——RPC 接口指挥着钱包，它属于回环地址、躲在应用后面，永远不该出现在公网接口上。三个端口、一个域名，其余一律拒绝：结算页面公开，节点是对等节点，钱包不可触达。暴露面定了，Lightning 的问题就从“新的暴露”变成“一次升级”。

Lightning：多出来的核心何时开始值回票价

Lightning 需要的不是更大的磁盘，而是在线率的承诺。通道依赖每个套餐都标配的固定 IPv4、不被封锁的 9735，以及一个不会消失几小时的节点——因为一个会打盹的路由节点会丢掉它承诺转发的付款。这就是为什么值得升级的是可靠性和核心数，从来不是存储容量。

两大主流实现都能跑在 BTCPay 的 Docker 部署之下——LND（其代码库文档说明了通道管理——lnd repository）和 Core Lightning（Core Lightning documentation）。链上结算的确认时间从几分钟到一小时不等；Lightning 以毫秒结算，买家的购物车不必等待。对一个结算页面来说，这就是“已付款待确认”和“已付款”的区别——而你的订单流程在每天清晨的第一单就能感受到这种差别。

运维上的新增项是恢复：在开启通道之前，导出静态通道备份——LND 下是 channel.backup——并存到这台服务器从未接触过的地方，因为通道是状态，而服务器是可替换的。瞭望塔（watchtower）为你缺席的时刻提供第二道防线。在 Titan 上，额外的核心可以毫无怨言地吸收路由负载；在 Prime 上，个人规模的小量路由表现良好，重度转发则会闹脾气。

流动性值得和备份同样慎重的对待：向连接良好的对等节点开通道，平衡入站与出站容量，克制住把资金全部倒进一条巨型通道的冲动。一个路由节点就是一个小做市商；它的价值在于连接的多样性，而不是任何一根管道的粗细——这套纪律同样可以优雅地缩小规模，适用于只想获得即时结算的结算页面。

错误示范：第一天就投入你锁定不起的资金开通道，而账单流还没证明过自己。通道是以月为单位计价的承诺；先用链上账单证明结算页面，再审慎地为路由注入资金。Lightning 是让 Titan 多出来的核心开始交房租的那次升级——它也是把一个“付款按钮”变成一台背负真实义务的 24/7 运营体的那个组件。

免 KYC 的契合是结构性的，不是表面的

把一个自托管支付处理器和一套跳过身份验证的托管配在一起，不是营销文案上的押韵——这是在两层封堵同一个缺口。一个不验证任何人证件的处理器，若坐在一台验证所有人证件的主机上，只是把卡点挪了个位置。端到端地看，这套部署两者都不要：令牌或邮箱注册、十九种币、零文件——而且从决定到上线，只需一个下午。

结算页面镜像着托管本身：买家可以用 BTC、XMR、各条网络上的 USDT，或账单提供的其他任何币种付款，而货款直接落进你的钱包——而不是某个处理商的 pooled 账户。XMR 在这里是一等公民，USDT 覆盖 TRC-20、ERC-20、BEP-20、SPL、Polygon、Arbitrum 和 Optimism。你的托管账单接受哪些币，从构造上就决定了你的顾客能用哪些币向你付款。

隐私姿态是基于事实的，不是玄学：不记录载荷或访客流量日志，保留账单和面板操作记录，连接元数据最多保留 24 h，DDoS 清洗包含在内。滥用行为按机房（数据中心）所在地的法律裁决——这正是司法辖区是一个真实决策的原因：Reykjavik 和 Zurich 因其法律制度分别有 +20% 和 +35% 的溢价，位置一览表印出了十二个站点各自适用的法律，而离岸指南则对它们逐一比较。

按结算页面的受众匹配辖区，取其外交含义：如果你的客户群集中在某个区域，一个你真正读得懂其法律制度的机房，胜过只看价格的随机挑选。溢价城市只有在它的特定保护对你的业务确实重要时才物有所值；对大多数结算页面而言，诚实的答案是十二个站点哪一个都行——让规格表做决定，而不是民间传说。

错误示范：把低门槛注册当作护身符。免 KYC 托管去掉的是一个数据中介；它不会让流量变得不可归因，滥用行为照样按机房所在地的法律裁决，和其他任何地方一样。把这种姿态用在它本来的用途上——你和你的基础设施之间少一道文书——而让运维安全住在你自己的习惯里：密钥、备份、更新，以及一个你维护得起来的威胁模型。

店铺同机部署：一笔诚实的算术

同一台服务器完全可以带上店铺，对多数小商户来说也理应如此——但配置的诚实必须把节点最糟糕的几分钟算进去，而不是它平均的下午。链同步、索引重建和 Lightning 重扫描，是节点扑向内存的时段，而那些时段恰恰是同机部署的店铺在付钱顾客眼中最显眼的时刻。

Prime 上的算术：节点、结算和店铺共享 8 GB，而店铺的峰值就是你的流量峰值，它与节点的峰值可能重合，也可能不重合。在测试环境中强制触发一次同步，用 docker stats 观察——Docker 文档中的资源限制一节演示了如何为每个服务设上限（Docker resource constraints）——并给节点设一个内存上限，让店铺在区块链偶尔发力时依然有问必答。

当峰值在实践中真的相撞，升级只是往上挪一档套餐：Titan，牌价 $24——年付折合 $19.20——核心翻倍到 8 个，内存翻两番到 32 GB ECC，把相撞问题整个溶解掉。要在店铺旺季之前升到 $19.20（年付折算）的 Titan，绝不要在旺季中途升；这个差价只是一行账单，而一次宕机则是一整个下午加上其声誉的余震。

预演技巧让决策从焦虑变成实证：在重要旺季到来之前，在一台测试机上，趁节点同步到一半时，对同机部署的整套服务回放一天的真实流量。如果店铺的错误率稳住，同机部署没问题，钱留在你口袋里；如果它开始摇晃，你就精确量出了这次促销需要多少余量，升档也就不再是猜谜。

典型的失误：按店铺的平均 CPU 配置，然后在第一场促销中撞上节点——这两个负载在打折日同时达到峰值，流量和结算在同一小时抵达。小目录、平稳流量：一台机器是对的。促销驱动的悬崖：把两者分开，让 DNS 决定谁来服务。无论哪种，盯内存而不是 CPU，因为内存才是节点赢下这场争执的地方。

门罗币账单与插件的现实

顾客可以通过 BTCPay 用 XMR 付款——经由社区插件而非核心流程，这个区别带着一项运维上的含义：插件的成熟度落后于核心，而生产环境的结算页面是天下最糟糕的公测场。如果门罗币账单逐渐长成你的主要流水，这套集成就配得上一次预演（staging）演练，然后才配面对一个付钱的陌生人。

核心流程是 BTC 和 Lightning：账单由受监视的地址生成，确认数由你自己的节点清点。社区插件通过在服务栈旁运行 monerod、以同样的自托管方式监视 XMR 目标地址，把门罗币嫁接进来——钱包的 RPC 接口在门罗开发者指南中有文档（Monero developer guides）。这套架构与 BTCPay 自身如出一辙：你的守护进程、你的钱包、你的验证，中间没有任何托管环节。

另一种做法是完全在 BTCPay 之外接收 XMR——一个静态地址，或第二个子域名上的一个极简网关——并让两条流程互不相识。这种切分用统一报表换取简单：BTC 和 Lightning 结算留在久经沙场的核心上，门罗一侧按自己的更新节奏跑自己的小栈。两者都保持自托管；不同的只是运维界面，门罗币支付指南介绍了直连路线。

无论选哪条路线，都要在上面演练恢复：在一台一次性机器上从助记词恢复门罗钱包，确认余额重新出现，然后才敢让这条流程接触营收。自主权的声明说起来便宜，发现它是假的却代价高昂——每个钱包做一次十分钟的恢复演习，就能把整套服务里每一句自主权口号，变成一条盖着日期的、经过验证的事实。

错误示范：因为演示环境跑通了，就在上线当天启用插件版本。插件的更新跟随社区的节奏而非你的节奏，而结算页面上的一次回退会吞掉没人会来报告的订单。在预演环境用真实金额试点、锁定版本、像运维人员一样读变更日志——支付方式的多元化是分阶段铺开的，从来不是一键切换；在新流程挣到自己的一席之地之前，兜底流程必须始终保持可用。

BTCPay 上线路线：按这个顺序执行

从身份和 DNS 开始：选定主机名，把它的 A 记录指向服务器，让 TLS 针对它自动化——在第一次安装之前，而不是之后。然后走受支持的路线：克隆 btcpayserver-docker 代码库，设置包括 BTCPAY_HOST 和修剪目标在内的环境变量，运行 btcpay-setup.sh，它会把整套服务一次性组装并启动起来。

在首次下载运行期间——本地 NVMe 上修剪模式需要数小时——顺手核实端口开口情况：80 和 443 有响应，8333 接受对等连接，按 ss -tlnp 检查没有其他任何暴露。节点亲自检查每一个区块，这正是全部意义所在；同步是整个项目唯一一段漫长等待，其后的一切与之相比都快。等待时长取决于存储类别而不是套餐大小：安装时定死的修剪目标让数据卷保持精悍，而小卷上不修剪地起步会在同步中途被填满，迫使整个下载重跑一遍。

在任何对外宣布之前，先用小额真实账单验证结算页面：先走链上，等端口和通道就绪后再上 Lightning——在为首条通道注资之前，先把 channel.backup 导出服务器之外。用真实金额和锁定版本在预演环境测试任何门罗插件，并让链上流程作为常备兜底保持可用，让其他一切围着它慢慢成熟。

趁着筹码还只是玩具规模，尽早把运维管道接好：接入你订单系统的 webhook、每日余额检查、磁盘和内存告警，以及一次完整的备份—恢复演练。在安静一周里建成的集成，会在喧闹一周里正常运转；承诺“以后再接”的集成，有一种有据可查的坏习惯——变成那次宕机本身。对一份不重要的副本把恢复流程跑一遍，让这套流程在第一场真正需要它的硬仗到来之前，就已经是已知量。

最后封上自主权的闭环：助记词和钱包备份存放在这台服务器从未去过的地方，并特意做一次恢复验证；docker stats 在首次同步和第一场促销期间全程盯守；再按基础加固清单执行每月的补丁节奏。从那以后，节点便低声嗡鸣——验证每一个区块，开具每一张账单，只服从区块链，不服从任何人的 API。