You set up your solo mining node. Your miner’s running. Everything looks fine on the local machine. But then you try connecting from another device on your network — or worse, you’re trying to mine remotely — and nothing works. The miner can’t see the node. Zero hashrate. Just… silence.
Yeah, I’ve been there.
The problem is usually port forwarding and firewall configuration. Your node is technically running, but it’s locked behind network barriers that you didn’t even know existed. The cool part is: once you understand how ports and firewalls work for solo mining, this becomes super straightforward.
Let me show you exactly how to open up your solo mining node the right way — without accidentally exposing your entire network to the internet.
Why Port Forwarding Matters for Your Solo Mining Node
Here’s the thing: when you run a full node for solo mining, it needs to communicate with two groups — other nodes on the blockchain network, and your own mining hardware.
Most cryptocurrency nodes use specific ports. Bitcoin Core uses port 8332 for RPC (the interface your miner talks to) and port 8333 for peer-to-peer connections. If those ports are blocked by your firewall, your miner literally can’t send work requests to the node.
Trust me on this: I spent three hours troubleshooting my first Bitcoin solo mining setup before I realized Windows Firewall was blocking port 8332. Three hours of thinking my configuration was wrong, when really it was just a firewall rule.
Local Network vs Remote Access
You need to think about two scenarios:
- Local mining: Your miner and node are on the same local network (like your home WiFi). You only need to configure local firewall rules.
- Remote mining: Your miner is somewhere else (maybe a friend’s GPU rig, or a hosted machine). You need port forwarding on your router AND firewall rules.
Most solo miners start with local setups. That’s honestly the smarter approach — remote solo mining introduces security risks that you need to understand first.
Understanding Firewall Rules for Solo Mining Nodes
Every operating system has a firewall. It’s basically a security guard that decides what network traffic gets in and what gets blocked. By default, most firewalls block incoming connections to protect your computer.
That’s great for security. Not so great when you’re trying to run a solo mining node.
Windows Firewall Configuration
If you’re running your node on Windows (check out my complete Windows solo mining guide if you haven’t set this up yet), here’s how to create the right firewall rules:
Open Windows Defender Firewall with Advanced Security. You can find this by typing “firewall” in the Windows search bar and selecting “Windows Defender Firewall with Advanced Security.”
Click “Inbound Rules” in the left panel, then “New Rule” on the right.
Select “Port” as the rule type, then click Next. Choose TCP and enter the specific port your node uses. For Bitcoin Core, that’s 8332 for RPC. For the P2P network port (8333), you’d create a separate rule.
Allow the connection, apply the rule to all profiles (Domain, Private, Public), and give it a descriptive name like “Bitcoin RPC Solo Mining.”
No joke: write down what each rule is for. I have like fifteen firewall rules now for different coins and testing setups, and I labeled them all “Mining Rule 1” at first. Huge mistake.
Linux Firewall Configuration
Linux systems typically use either UFW (Uncomplicated Firewall) or iptables. If you’re running a dedicated mining node on Linux (my Linux solo mining setup guide covers the full OS configuration), UFW is way easier to work with.
First, check if UFW is active:
sudo ufw status
To allow Bitcoin Core RPC traffic on port 8332 from your local network only (let’s say your local network is 192.168.1.0/24):
sudo ufw allow from 192.168.1.0/24 to any port 8332 proto tcp
This rule allows any device on your local network (192.168.1.x) to connect to port 8332, but blocks everything else. That’s exactly what you want for local solo mining.
For the P2P port (8333), you might want to allow all incoming connections so your node can sync with the network properly:
sudo ufw allow 8333/tcp
The difference is important. Port 8333 talks to other Bitcoin nodes around the world — that’s how your node stays synced with the blockchain. Port 8332 is your mining interface — you don’t want random people on the internet sending mining requests to your node.
Common Ports for Different Cryptocurrencies
Each cryptocurrency uses different default ports. Here are the ones I use most often:
- Bitcoin: RPC 8332, P2P 8333
- Litecoin: RPC 9332, P2P 9333
- Monero: RPC 18081, P2P 18080
- Ravencoin: RPC 8766, P2P 8767
- Kaspa: RPC 16110, P2P 16111
You can usually find the default ports in the coin’s configuration file or documentation. Most nodes let you change these ports if needed, but honestly, stick with defaults unless you have a specific reason to change them.
Router Port Forwarding for Remote Solo Mining Access
Here’s where things get more complex. If you want to connect a miner to your node from outside your local network, you need to configure port forwarding on your router.
Port forwarding tells your router: “When someone connects to this specific port from the internet, forward that traffic to this specific device on my local network.”
Finding Your Router’s Configuration Page
Every router is different, but the process is similar. You access your router’s web interface, usually by typing its IP address into a browser. Common router IPs are:
- 192.168.1.1
- 192.168.0.1
- 10.0.0.1
If none of those work, open Command Prompt (Windows) or Terminal (Linux/Mac) and type ipconfig (Windows) or ip route (Linux). Look for “Default Gateway” — that’s your router’s IP.
You’ll need your router’s admin username and password. If you never changed it, check the sticker on the router itself or look up the default credentials for your router model online.
Creating a Port Forwarding Rule
Once you’re in your router’s interface, look for a section called “Port Forwarding,” “Virtual Servers,” “NAT,” or something similar. The exact name depends on your router brand.
You’ll need a few pieces of information:
- Service/Application Name: Something descriptive like “Bitcoin Solo Mining”
- External Port: The port number traffic will come to (e.g., 8332)
- Internal Port: Usually the same as external port (8332)
- Internal IP Address: The local IP of your mining node computer
- Protocol: TCP
The internal IP address is crucial. This is the local IP of the computer running your node. On Windows, find it with ipconfig and look for “IPv4 Address.” On Linux, use ip addr show.
Important: Most home networks use DHCP, which means your computer’s local IP can change when you restart your router. You should set a static IP for your mining node, or configure a DHCP reservation in your router so your node always gets the same local IP.
Security Considerations for Port Forwarding
Look, I can’t stress this enough: opening ports to the internet is risky if you don’t do it right.
Here’s what you need to know. When you forward a port through your router, anyone on the internet can potentially connect to that port. For cryptocurrency nodes, that means someone could try to exploit your RPC interface.
Always, always configure RPC authentication. For Bitcoin Core and most other nodes, that means setting an rpcuser and rpcpassword in your configuration file. The password should be strong — like 20+ random characters strong.
In your bitcoin.conf file (or equivalent for other coins), you should have:
rpcuser=yourusername
rpcpassword=your_super_secure_password
rpcallowip=192.168.1.0/24
The rpcallowip line restricts which IP addresses can connect. If you’re only mining locally, keep it to your local network range. If you need remote access, you can specify the exact IP address of your remote miner instead of opening it to everyone.
Depending on your setup, you might want to use a VPN instead of direct port forwarding. Services like Tailscale or ZeroTier create encrypted tunnels between your devices without exposing ports to the public internet. That’s what I use now for remote mining setups.
Testing Your Port Forwarding Solo Mining Node Configuration
You’ve configured the firewall. You’ve set up port forwarding. Now you need to test if it actually works.
Local Network Testing
First, test from another device on your local network. Grab a laptop or phone connected to the same WiFi and try to access your node.
For Bitcoin Core, you can test the RPC connection with a simple curl command from another computer:
curl --user yourusername:yourpassword --data-binary '{"jsonrpc":"1.0","id":"test","method":"getblockcount","params":[]}' -H 'content-type: text/plain;' http://NODE_LOCAL_IP:8332/
Replace NODE_LOCAL_IP with your node’s local IP address. If you get a response with a block height, your node is accessible and working.
If it times out or fails, check your firewall rules first. That’s the most common issue.
External Access Testing
If you’ve forwarded ports through your router for remote access, you need to test from outside your network. The easiest way is to use your phone’s cellular data (not WiFi) or ask a friend to test from their internet connection.
You’ll need your public IP address. Google “what is my ip” and Google will show it to you. Then try the same curl command, but replace the local IP with your public IP:
curl --user yourusername:yourpassword --data-binary '{"jsonrpc":"1.0","id":"test","method":"getblockcount","params":[]}' -H 'content-type: text/plain;' http://YOUR_PUBLIC_IP:8332/
If this works, your port forwarding is configured correctly. If it doesn’t, double-check your router’s port forwarding rules and make sure your ISP isn’t blocking the port.
Some ISPs block common ports or don’t allow inbound connections on residential plans. If you’re having issues, you might need to use a non-standard port or consider a VPN solution.
Connecting Your Miner
Once ports are open and tested, you can connect your mining software. The syntax depends on your miner, but it generally looks like this:
For local mining: -o http://192.168.1.X:8332 -u rpcuser -p rpcpassword
For remote mining: -o http://YOUR_PUBLIC_IP:8332 -u rpcuser -p rpcpassword
Check my guides for TeamRedMiner setup on AMD or T-Rex Miner for NVIDIA for coin-specific connection examples.
If you’re running multiple miners or want easier management, you might want to set up a stratum proxy between your miners and node. This adds a layer that handles miner connections and work distribution.
Advanced Configuration: Multiple Miners and Stratum Proxies
Running one miner on one node is straightforward. But what if you have three GPUs, two ASICs, and you want them all solo mining different coins through different nodes?
Yeah, it gets complicated fast.
Stratum Proxy for Solo Mining
A stratum proxy sits between your miners and your node. Your miners connect to the proxy using the stratum protocol (which most miners support natively), and the proxy translates those requests to the node’s RPC interface.
This is particularly useful for solo mining because:
- Most miners are designed for pool mining and expect stratum
- You can connect multiple miners to one proxy
- The proxy can handle difficulty adjustments for your miners
- You only need to forward one port (the proxy’s port) instead of the node’s RPC port
I wrote a detailed guide on setting up a stratum proxy for solo mining that covers the exact configuration. The short version: you run software like solo-ckpool or miningcore that implements the stratum protocol and connects to your node.
For port forwarding with a proxy, you’d forward the proxy’s stratum port (often 3333 or similar) instead of the node’s RPC port. This adds a security layer since you’re not exposing the node’s RPC interface directly.
Managing Multiple Nodes
If you’re solo mining multiple coins (which honestly makes more sense than solo mining just Bitcoin with low hashrate), you’ll run multiple nodes. Each needs its own ports configured.
You can run multiple nodes on the same machine by changing the port numbers in each coin’s configuration file. For example:
- Bitcoin Core: RPC 8332, P2P 8333
- Litecoin Core: RPC 9332, P2P 9333
- Ravencoin: RPC 8766, P2P 8767
Each coin’s node gets its own firewall rule, and if you need remote access, its own port forwarding rule in the router.
This is where good documentation becomes critical. I keep a spreadsheet with each coin, its ports, its local IP (if running on different machines), and which miner connects to it. Sounds nerdy, but trust me — you’ll forget this stuff otherwise.
Dynamic DNS and Static IP Considerations
Here’s a problem I ran into after a few months: my ISP changed my public IP address, and suddenly my remote miner couldn’t connect anymore.
Most residential internet connections use dynamic IP addresses, meaning your public IP can change periodically. If you’re using port forwarding for remote solo mining access, this breaks your setup every time your IP changes.
Dynamic DNS Solutions
Dynamic DNS (DDNS) solves this problem. Instead of connecting to your IP address directly, you connect to a domain name that automatically updates when your IP changes.
Services like No-IP, DynDNS (now Oracle Cloud), or Dynu offer free DDNS. You create an account, choose a hostname (like yourminingnode.ddns.net), and install their client software on your node computer.
The client periodically checks your public IP and updates the DNS record automatically. Then your remote miner connects to yourminingnode.ddns.net:8332 instead of your IP address directly.
Many routers have built-in DDNS support for popular services. Check your router’s web interface — if it’s there, you can configure it without installing client software.
Static IP from Your ISP
The alternative is getting a static IP from your ISP. This guarantees your public IP never changes, but it usually costs extra — like $10-30/month depending on your ISP.
For serious remote solo mining setups, a static IP is worth considering. It’s more reliable than DDNS and eliminates one potential point of failure.
Look, I’m 13 and can’t really convince my parents to pay for a static IP just for my mining experiments, so I use DDNS. It works fine, honestly.
Security Best Practices for Exposed Solo Mining Nodes
Opening ports to the internet is inherently risky. Here are the security measures you should take seriously:
Strong RPC Authentication
I mentioned this earlier, but it’s worth repeating. Use a strong rpcpassword in your node configuration. Generate it randomly — don’t use anything you could remember. Your node will remember it for you.
Many nodes support rpcauth instead of plain rpcpassword, which uses hashed credentials. Even better for security.
IP Whitelisting
If you know the IP address of your remote miner, use rpcallowip to restrict access to only that IP. Don’t allow 0.0.0.0/0 (all IPs) unless you absolutely have to.
For dynamic IPs on the miner side, this gets tricky. You might need to allow a range or use VPN solutions instead.
Fail2Ban for Linux Nodes
If you’re running a Linux node with exposed ports, consider installing Fail2Ban. This monitors connection attempts and automatically bans IPs that show suspicious behavior (like repeated failed login attempts).
It’s not specific to mining, but it adds a layer of protection against brute-force attacks on your RPC interface.
Regular Security Updates
Keep your node software updated. Cryptocurrency node software occasionally has security patches, and running outdated versions with exposed ports is asking for trouble.
Subscribe to your coin’s development mailing list or follow their GitHub for security announcements.
VPN Alternative
Honestly, the most secure approach is not to forward ports at all. Use a VPN solution like Tailscale or ZeroTier that creates an encrypted network between your devices.
With Tailscale, your node and remote miner both install the client and join the same private network. They can communicate as if they’re on the same local network, but everything is encrypted and no ports are exposed to the public internet.
This is what I’d recommend if you’re serious about remote solo mining. It’s a bit more setup initially, but way more secure and you don’t have to worry about port forwarding at all.
Troubleshooting Common Port Forwarding Issues
Even with everything configured correctly, stuff breaks. Here are the issues I’ve encountered and how to fix them:
Miner Can’t Connect Locally
If your miner can’t connect to your node on the same network, the issue is usually the firewall. Not the router — the firewall on the node computer itself.
Double-check your firewall rules. On Windows, make sure the rule is enabled for the Private network profile (that’s what home networks typically use). On Linux, verify your UFW rules with sudo ufw status and make sure they allow your miner’s IP.
Test with the curl command I showed earlier. If curl works from another computer but your miner doesn’t, the issue is in the miner configuration, not the network.
Remote Connection Times Out
This is usually port forwarding configuration in the router. Verify:
- The port forwarding rule is enabled
- The internal IP matches your node’s current local IP
- The protocol is set to TCP
- Your ISP isn’t blocking the port
Some ISPs block common ports on residential connections. Try using a non-standard port (like 18332 instead of 8332) and updating both your node configuration and port forwarding rule.
Connection Works Then Stops
If remote mining works initially but stops after a few hours or days, your node’s local IP probably changed. This happens if you’re using DHCP and your router reassigned IPs.
Set up a DHCP reservation for your node’s MAC address in your router, or configure a static IP on the node itself.
On Windows: Network Settings → Change Adapter Options → Right-click your network adapter → Properties → Internet Protocol Version 4 → Use the following IP address
On Linux: Edit your network configuration (this depends on your distro — Ubuntu uses Netplan, others might use /etc/network/interfaces).
Node Responds But Miner Shows Zero Hashrate
If your miner connects successfully but shows 0 H/s, the node is probably still syncing. Check your node’s block height against a block explorer.
For Bitcoin, you can run bitcoin-cli getblockcount and compare it to the current height on a site like blockchain.com. If your node is behind, wait for it to sync completely.
Some nodes (especially Bitcoin Core) won’t serve mining work until they’re fully synced. That naturally depends on your internet speed and hardware — initial Bitcoin sync can take days.
Hidden Gem: Port Forwarding for HiveOS Remote Management
If you’re running GPU rigs with HiveOS for solo mining, there’s a neat trick most people don’t know about.
HiveOS has a built-in web interface for local management on port 80. By default, you can only access this on your local network. But with port forwarding, you can manage your rig from anywhere.
Forward port 80 (or change HiveOS to use a non-standard port like 8080) to your HiveOS rig’s local IP. Then you can access the web interface from anywhere using http://YOUR_PUBLIC_IP:8080.
Fair warning: secure this properly. HiveOS has a default password that you should change immediately. Also consider using a non-standard port since port 80 gets scanned constantly by bots.
I use this when I’m at school and want to check if my rig is still running or needs a reboot. Pretty handy, actually.
Realistic Assessment: When Remote Solo Mining Makes Sense
Let me be honest with you. For most solo miners, especially those starting out, remote access adds complexity you probably don’t need.
If your node and miner are both at home, keep them on your local network. It’s simpler, more secure, and you don’t need to worry about port forwarding at all.
Remote solo mining makes sense in specific scenarios:
- You have a GPU rig hosted somewhere else (like a data center or friend’s place) and want to point it at your home node
- You’re running a powerful node server and want to mine from multiple locations
- You’re traveling but want to keep monitoring and mining
But here’s the thing — if you’re solo mining with low hashrate (which most of us are), the odds of hitting a block are already tiny. Adding network latency and potential connection issues from remote mining doesn’t help.
For context: solo mining Bitcoin with anything less than several hundred TH/s is basically a lottery ticket. The current Bitcoin price is $66,312, block reward is 6.25 BTC, and difficulty is insanely high. Your expected time to find a block might be measured in centuries.
That doesn’t mean you shouldn’t do it — I still solo mine Bitcoin with my modest setup because it’s fun and educational. But be realistic about why you’re doing it.
For actual block-finding potential, consider solo mining lower-difficulty coins like Ravencoin, Ergo, or Kaspa. You’ll still need port forwarding if mining remotely, but at least you have a realistic shot at hitting blocks.
FAQ: Port Forwarding Solo Mining Node Questions
Do I need port forwarding for local solo mining?
No, if your miner and node are on the same local network, you only need to configure firewall rules to allow local connections. Port forwarding is only necessary when you need to access your node from outside your local network — like if you’re mining remotely from another location.
Which ports do I need to forward for Bitcoin solo mining?
For Bitcoin Core solo mining, you need port 8332 (RPC) forwarded to your node’s local IP if you’re mining remotely. Port 8333 (P2P) should also be forwarded if you want optimal connection to the Bitcoin network, but this is less critical for mining specifically. Always secure port 8332 with strong RPC authentication since it controls your node.
Is it safe to forward mining ports through my router?
Port forwarding inherently exposes your node to internet traffic, which carries security risks. To minimize these risks: use strong RPC passwords, limit access with rpcallowip to specific IPs, keep your node software updated, and consider using a VPN solution like Tailscale instead of direct port forwarding. Never forward ports without proper authentication configured on your node.
Why does my miner connect but show zero hashrate?
If your miner successfully connects to your node but displays 0 H/s, your node is likely still syncing with the blockchain. Most cryptocurrency nodes won’t distribute mining work until they’re fully synchronized. Check your node’s block height against a public block explorer — if it’s behind, wait for the sync to complete before mining.
Can I use the same ports for multiple cryptocurrency nodes?
No, each node needs its own unique ports if running on the same machine. You can’t have two programs listening on port 8332 simultaneously. Each cryptocurrency typically has default ports (Bitcoin uses 8332/8333, Litecoin uses 9332/9333, etc.), and you’ll need separate firewall and port forwarding rules for each node you run.