How Much Internet Does an ASIC Miner Use? Bandwidth, Data, and Reliable Network Setup

Published: 2026-08-26 Updated: 2026-08-26 Evidence checked: 2026-08-26

An ASIC miner usually needs very little internet bandwidth. Bitmain estimates about 500 MB of data per miner per month and uses 1 Mbps per 150 machines as a fleet-planning rule. Treat those figures as starting points, not guarantees: firmware, monitoring, pool protocol, and remote access can change usage. A stable wired connection with low packet loss matters more than headline download speed.

The short answer: low traffic, high reliability

Mining does not send completed hashes across the internet. The pool sends compact jobs, and the miner returns shares that prove work. That exchange is tiny beside video streaming, cloud backups, or operating-system downloads.

For an ANTMINER, Bitmain publishes two useful planning figures:

• An estimated 500 MB of data per miner per month.
• A bandwidth formula of 1 Mbps for every 150 machines.

Those numbers agree on the main point: raw throughput is rarely the constraint. They do not create a universal data allowance. Different firmware, pools, coins, monitoring agents, management sessions, and network conditions produce different traffic. Measure the connection you actually run before choosing a tightly capped mobile or satellite plan.

Bandwidth and data usage are different questions

Bandwidth is the rate a connection can carry, normally shown in Mbps. Data usage is the amount transferred across a billing period, normally shown in MB or GB. A miner can need little bandwidth at any instant yet still require a reliable, always-on link.

Question	Unit	What it tells you	What it does not tell you
How fast must the link be?	Kbps or Mbps	Whether jobs, shares, DNS, and management traffic fit without congestion	How much data the miner uses in a month
How much data will be billed?	MB or GB per month	Whether a capped connection has enough allowance	Whether the link is stable
How responsive is the path?	Latency over time	How quickly traffic reaches the pool	Whether packets are being lost
How reliable is the path?	Loss, reconnects, uptime	Whether the miner can remain connected and submit work	Whether the plan has a large headline speed

A 100 Mbps home plan does not make an unstable cable reliable. A 4G connection with plenty of unused data can still drop shares when signal quality changes. Conversely, a modest wired connection may be entirely adequate for several miners when it is clean, uncongested, and monitored.

Use this bandwidth and data worksheet

Do not size a capped plan from a forum figure alone. Record traffic at the router, gateway, or dedicated network interface for at least seven ordinary days. Include a normal mining period, a pool reconnect, and any scheduled monitoring. Exclude unrelated household traffic if the router can separate it.

Worksheet item	Your value	How to obtain it
Number of miners	___	Count active devices, not spare units
Measurement period	___ days	Use consecutive ordinary operating days
Miner upload	___ GB	Per-device or mining-network interface counter
Miner download	___ GB	Same counter and period
Firmware/maintenance traffic	___ GB	Record separately because it is intermittent
Remote monitoring/VPN traffic	___ GB	Include dashboards and management tools
Reconnects during period	___	Router, miner, or pool logs
Total measured traffic	___ GB	Upload + download + relevant overhead
Projected 30-day traffic	___ GB	Formula below
Planned headroom	___%	Choose for your operational risk and billing terms

Use this projection when your measurement period is not exactly 30 days:

Projected 30-day data (GB) = measured data (GB) / measured days x 30

Then add a clearly chosen reserve:

Plan allowance (GB) = projected 30-day data x (1 + headroom percentage)

The reserve is an operating choice, not a mining-protocol constant. A metered failover link used only during outages needs a different allowance from a mobile link carrying the miners full time.

If your gateway reports average throughput instead of accumulated bytes, use:

Monthly data (GB) = average traffic (kbps) x 86,400 x days / 8,000,000

Worked example using an observed rate

Suppose a dedicated miner interface averages 10 kbps across a 30-day period. This is a hypothetical measurement, not a claim about a particular model:

10 x 86,400 x 30 / 8,000,000 = 3.24 GB per month

If the same miner's router counter shows only 0.6 GB, trust the correctly isolated byte counter over the illustrative rate. Check whether the rate display included LAN broadcasts, monitoring traffic, other devices, or short bursts that were averaged incorrectly.

What creates ASIC miner internet traffic?

The mining session itself is only one part of the total.

• Pool jobs: The pool sends work to the miner whenever a new job is available.
• Share submissions: The miner returns qualifying shares. Share frequency depends on the pool's assigned difficulty and the miner's hashrate.
• Connection maintenance: DNS lookups, TCP sessions, keepalives, retries, and failover checks add small amounts of traffic.
• Monitoring: Farm agents, metrics collectors, mobile dashboards, and alerting can exceed the miner's core Stratum traffic.
• Remote administration: Repeatedly loading dashboards, viewing logs, or using remote desktop tools adds traffic and security exposure.
• Firmware and support files: Downloads are intermittent but can dominate a day's data on a capped plan.
• Other devices: Cameras, laptops, cloud backups, and automatic updates on the same router are not miner traffic, even though the internet provider bills them together.

That is why a router-level monthly total can be misleading. Put miners on a dedicated network segment or at least identify their individual addresses before measuring.

Why connection quality affects accepted work

A miner can continue hashing during a brief delay, but it needs current pool work and a working return path for shares. If the link repeatedly drops, the machine reconnects, requests new jobs, and may submit work too late. Bitmain specifically identifies network instability, packet loss, unstable pool connections, and high rejection rates as factors that can reduce working hashrate.

Watch trends rather than chasing one universal latency target. Pools are distributed differently, routes change by location, and protocols behave differently. Establish a stable baseline for each pool endpoint, then investigate meaningful changes in:

• accepted and rejected share counts;
• reconnect frequency and connection duration;
• latency distribution, not just one ping result;
• packet loss to the router, provider, and pool path;
• DNS failures;
• pool-side worker uptime;
• miner-side network and system logs.

If rejects increase while temperature, power, and local hashrate remain steady, the network path deserves attention. If local hashrate also falls, check the machine rather than assuming every rejected share is an internet problem. The ASIC miner maintenance checklist helps separate thermal and hardware faults from connectivity faults.

A reliable network setup for one home ASIC

1. Use wired Ethernet

Connect the miner directly to a router or managed switch with a sound Ethernet cable. Bitmain states that ANTMINERs use Ethernet rather than Wi-Fi. Avoid temporary wireless bridges unless there is no practical wired route and you can monitor the bridge independently.

2. Give the miner a predictable local address

Use a DHCP reservation or a documented static configuration that fits your router. A predictable address makes monitoring and troubleshooting easier. Do not expose the miner's administration page directly to the public internet.

3. Configure real pool failovers

Use a current primary endpoint and working backup entries. Confirm each endpoint's worker syntax and port from the pool's official instructions. Duplicating one dead address in all rows is not redundancy. Follow the ASIC miner pool settings guide for the field-by-field setup.

4. Protect the network equipment's power

A miner cannot submit work when the router or fiber terminal is off. If uninterrupted mining matters, include the modem or optical terminal, router, and necessary switch in the power-continuity plan. Size and maintain that equipment according to its manufacturer instructions.

5. Use secure remote access

Keep management on the local network or behind a properly configured VPN. Change default credentials, update supported firmware, and disable services you do not use. A public miner dashboard is a security problem, not a convenient monitoring shortcut.

6. Create alerts that show the failure domain

Use both pool-side and local alerts if possible. A pool alert says a worker disappeared; a local monitor helps distinguish a dead miner from an upstream outage. Record timestamps so you can compare miner, router, and pool events.

How the design changes for a small farm

The core traffic per miner remains modest, but the cost of a shared failure grows with every machine behind the same device. Bitmain's facility guidance recommends redundant providers for large sites and describes separated production and administration networks. A small farm can apply the same principles without copying an enterprise design blindly.

Scale	Practical design	Main risk to avoid
1-2 miners	Wired router, documented addresses, valid pool backups, basic outage alert	Assuming high download speed guarantees stability
3-20 miners	Managed switch, separate mining network, labeled cables, router and switch monitoring	One cheap switch or power adapter becoming the hidden single point of failure
20+ miners	Capacity calculation, redundant gateway plan, spare network hardware, tested failover, separate management access	Buying redundancy that has never been tested
Hosted miners	Written visibility into provider connectivity, pool access, incident response, and monitoring	Treating the host's internet as unmeasurable or automatically reliable

If you are deciding whether to keep machines on your own connection at all, compare the operational tradeoffs in ASIC miner hosting vs. home mining.

For fleet planning, Bitmain's published rule is:

Required upstream and downstream bandwidth (Mbps) = number of miners / 150

That formula yields 20 Mbps for 3,000 machines. It is a vendor planning rule, not permission to provision a link with zero headroom or no redundancy. Monitoring, firmware distribution, remote administration, security systems, and non-mining users require separate capacity.

Network reliability checklist

Before leaving a miner unattended, confirm each item:

• The miner uses a known-good wired Ethernet cable.
• Router, switch, and miner ports negotiate normally without rising error counts.
• The miner has a documented local address and device name.
• Default administration credentials have been changed.
• The management page is not directly exposed to the public internet.
• Primary and backup pool entries are current and independently tested.
• Each miner has a distinct worker name.
• DNS resolution works after a router restart.
• Pool-side offline alerts reach the operator.
• Local monitoring can distinguish miner failure from internet failure.
• Monthly upload and download counters are recorded for capped links.
• Firmware downloads and remote-access traffic are included in the data plan.
• The router, switch, and provider terminal are included in power-continuity planning.
• Spare cables and a known-good switch port are available for diagnosis.
• The failover connection has been tested under controlled conditions.

Troubleshooting decision tree

Use one change at a time so the result means something.

1. Is the miner visible on the LAN?
   • No: Check link lights, cable, switch port, DHCP lease, and local addressing.
   • Yes: Continue to step 2.
2. Can the miner resolve and reach the pool endpoint?
   • No: Check DNS, gateway, firewall, provider status, and pool hostname.
   • Yes: Continue to step 3.
3. Does the pool show the worker online?
   • No: Verify URL, port, account, and worker syntax; then test a documented backup endpoint.
   • Yes: Continue to step 4.
4. Are accepted shares increasing normally?
   • No: Compare rejects, latency, packet loss, temperature, local hashrate, and miner logs against the last stable period.
   • Yes: The path is working; investigate only if data usage or reconnects exceed your baseline.
5. Does switching to a backup provider restore stable shares?
   • Yes: Record the outage boundary and investigate the primary provider or route.
   • No: Focus on the local network, power, miner configuration, and hardware before changing pools again.

Data-cap decisions for mobile, satellite, and failover links

The published 500 MB/month estimate suggests that the mining session itself can fit comfortably inside many capped plans. The wrong conclusion is to buy a 500 MB plan. Provider overhead, firmware, monitoring, VPN traffic, retransmissions, and other devices can consume the margin quickly.

Use a seven-day isolated measurement, project it to 30 days, and add headroom that reflects the cost of exceeding the cap. If the connection is only a failover, test how much traffic it carries during a controlled primary outage. Also confirm whether the provider uses carrier-grade NAT, blocks ports, changes addresses, or de-prioritizes traffic; data allowance alone does not establish suitability.

Open discussion: publish measurements with enough context

Real measurements are most useful when they include the miner model, firmware, coin and pool protocol, monitoring tools, number of devices, measurement point, and observation period. A bare claim such as "my miner uses 1 GB" cannot show whether the figure includes dashboard sessions, firmware downloads, or other clients.

If you operate a miner on a capped or failover connection, share the upload and download totals separately and note any reconnects or pool changes. A collection of well-scoped observations is more valuable than forcing every installation into one universal number.

Frequently asked questions

Can an ASIC miner run on a 1 Mbps internet connection?

For bandwidth alone, Bitmain says 1 Mbps can support up to 150 ANTMINERs, so one miner should not need a fast connection. That does not mean every 1 Mbps service is suitable. The connection still needs stable upstream and downstream traffic, working DNS, low packet loss, and enough data allowance. Test the actual pool path and watch accepted shares, reconnects, and router errors before relying on a slow or heavily contended service.

How much data does one ASIC miner use per month?

Bitmain estimates about 500 MB per ANTMINER per month, but that figure should be treated as a starting point. Firmware downloads, monitoring software, pool protocol, retries, VPN traffic, and remote dashboard use can increase the total. Measure upload and download bytes for the miner's own address over at least seven ordinary days, project the result to 30 days, and add a reserve before selecting a capped plan.

Does higher internet speed increase mining hashrate?

Not directly. The hashboards perform the calculations locally, so buying a faster download tier does not make the silicon hash faster. Internet quality affects whether the miner receives current jobs and returns shares reliably. Once bandwidth is adequate, lower packet loss, fewer reconnects, dependable DNS, and a stable route to the pool matter more than a larger headline Mbps number. Power, temperature, tuning, and hardware health still determine local hashrate.

Can I connect an ASIC miner over Wi-Fi or a mobile hotspot?

ANTMINER guidance specifies wired Ethernet rather than built-in Wi-Fi. A third-party bridge or mobile router may provide connectivity, but it adds another radio link, power supply, and failure point. Mobile service can also change with signal strength and congestion. If it is your only option, isolate the miner's traffic, monitor reconnects and packet loss, secure remote access, and test the setup under the same conditions in which it will run unattended.

What internet metrics should I monitor for an ASIC miner?

Track accepted and rejected shares, worker uptime, reconnects, latency over time, packet loss, DNS failures, and interface error counters. Compare them with the miner's temperature, power stability, and local hashrate so you do not blame the network for a hardware fault. For capped plans, record upload and download bytes separately. The best alert is one that helps identify the failure domain: miner, local network, provider, DNS, or pool.

Do I need a second internet provider for mining?

One home miner may not justify a second full-time provider if occasional downtime is acceptable. The decision changes as the value of offline hashrate rises. For a farm, provider redundancy, separate physical routes, spare network hardware, and tested failover can reduce a shared outage. Calculate the expected downtime cost, compare it with backup-service cost, and test the failover path; an unused backup that cannot reach the configured pools is not redundancy.

References

1. Bitmain Support: Do's and Don'ts of a New ANTMINER
2. Bitmain Support: Network Bandwidth and Load
3. Bitmain Support: Insufficient Hashrate of Miner
4. Bitmain Support: Network and Wiring System
5. Braiins Academy: Bitcoin Mining Setup