BTCPay Docker users must opt into Tor at their next update to keep onion access

Lời nói đầu:BTCPay Tor access needs an explicit Docker choice during maintenance, alongside separate restrictions on private-service HTTP requests.

Operators running the Bitcoin payment software BTCPay Server through its standard Docker deployment must explicitly select Tor at their next setup or update if they want to retain onion access. The change removes Tor from the automatically included components, making a previously bundled service an administrators configuration choice.

Related Asset Bitcoin #1 BTC · $82,948.73 24-hour change: up 0.66% Loading price history… 24H Up 0.66% 7D Down 2.35% 30D Up 7.48%

BTCPay detailed the deployment change in its Oct. 5 announcement accompanying version 2.4.5. The official GitHub release page records the software release on Oct. 6. For existing installations, the relevant trigger is their next Docker setup or update.

The change matters to Docker operators who rely on Tor, including access through their servers onion address, but previously received it through the core BTCPay Server fragment. Fragments are the configuration components used to assemble the Docker stack.

BTCPay advises administrators to review the deployment changes before updating. After updating to 2.4.5, its instruction for enabling Tor is:

sudo btcpay-fragments add opt-add-tor

Tor remains supported, and BTCPay says existing data stays in the current Tor volumes. That preserves stored data; continued onion access still depends on including and running Tor in the deployment.

BTCPay Server documentation describes the optional Tor fragment opt-add-tor as adding hidden services and selected onion connectivity. Operators can inspect configuration using btcpay-fragments show, which does not change configuration and reports saved additional and excluded fragments alongside the effective fragments from the last generated manifest.

Fragment-changing commands require root and reapply setup immediately.

Private services need separate exceptions

The 2.4.5 release notes also identify a breaking change for outbound HTTP requests: private-network destinations are blocked by default for Lightning connections, LNURL requests, invoice notification URLs and webhooks. The restriction is intended to prevent server-side request forgery, or SSRF.

With that protection enabled, operators intentionally using private services must allow the needed destinations through ssrfexceptions.

BTCPays operator guide says to restart the application and exercise the affected integration after changing the setting.

Miễn trừ trách nhiệm

Các ý kiến ​​trong bài viết này chỉ thể hiện quan điểm cá nhân của tác giả và không phải lời khuyên đầu tư. Thông tin trong bài viết mang tính tham khảo và không đảm bảo tính chính xác tuyệt đối. Nền tảng không chịu trách nhiệm cho bất kỳ quyết định đầu tư nào được đưa ra dựa trên nội dung này.
Bài viết trước

Phân tích XM chi tiết cho trader Việt: Nền tảng, phí, tài khoản và điều kiện giao dịch

Bài tiếp theo

Nhà giao dịch mất 6.6 triệu USD Bitcoin sau khi mua ví Ledger mới