Перейти к основному содержанию

Network Connectivity

Your connectivity status determines how well aMule can exchange data with other peers. The two networks aMule uses express this status differently:

  • On eD2k, you get a High ID when your TCP port is reachable from the internet, or a Low ID when it is not. A Low ID means many servers reject you, two Low ID clients cannot exchange data, and download speeds are reduced.
  • On Kademlia, the equivalent status is open (UDP port reachable) or firewalled (blocked or remapped). The two statuses are independent — you can have a High ID on eD2k but still be firewalled on Kad.

This page explains the practical steps to make your ports reachable so you get a High ID on eD2k and an open status on Kademlia.

Ports used by aMule​

aMule uses three ports to communicate with other clients and servers. All three can be changed in Preferences → Connection.

PortProtocolDirectionPurpose
4662 (configurable)TCPIncoming + OutgoingPrimary data port. Client-to-client transfers, identification, file requests. Must be open for High ID.
4665 (= TCP port + 3)UDPIncoming + OutgoingeD2k server UDP port. Extended server searches and global source queries sent to eD2k servers. Recommended for extended stats on eD2k.
4672 (configurable)UDPIncoming + OutgoingExtended eMule protocol, queue rating, file re-ask ping, and Kademlia. Required for Kademlia "open" status.

Additionally:

PortProtocolDirectionPurpose
4661TCPOutgoing onlyConventional eD2k server listening port. aMule connects to whatever port each server in the server list defines — it is not hardcoded in aMule nor client-configurable.
4711TCPIncomingamuleweb (legacy WebUI).
4712TCPIncomingExternal Connections (EC) — used by amulegui, amuleapi and amulecmd.
4713TCPIncomingamuleapi HTTP interface (REST API + Web UI). Default port; configurable.

Minimum port requirements by network​

The minimum requirements to avoid connectivity penalties differ for each network:

eD2k network:

  • TCP port 4662 open → High ID (and full peer connectivity).
  • UDP port 4665 open → recommended: provides extended file statistics and global searches. Not required for High ID.
  • You can still connect to eD2k with no ports open, but you will receive a Low ID and have significantly reduced download performance.

Kademlia network:

  • TCP port 4662 and UDP port 4672 both open → Kademlia status "open" (full participation).
  • If either is blocked, Kad reports "firewalled" for that side — you stay connected and can still download, just with reduced efficiency.

See Kademlia connectivity below for what "open" and "firewalled" mean and how the buddy relay works.

Step 1 — Identify your ports​

  1. Start aMule and open Preferences → Connection.
  2. Note the value in the Standard client TCP Port field (default: 4662).
  3. Note the value in the Extended client UDP Port field (default: TCP + 3 = 4665).
  4. The Kad UDP port (4672) is shown separately in the Preferences → Connection page.
  5. Ensure the "Extended UDP port (Kad / global search)" checkbox is ticked — if it is unchecked, the UDP port (4672) is disabled and Kademlia cannot reach "open" status.

You can verify whether a port is reachable from outside your network using an online port checker (see Testing your port status below). A closed result means incoming connections to that port are being blocked — either by a firewall, a router doing NAT, or both.

Step 2 — Open the ports in your firewall​

If a firewall is running on your machine (for example, nftables on Linux, pf on BSD, or the Windows Firewall), you need to add rules that allow incoming connections on the three aMule ports.

If you do not administer your own firewall (e.g. corporate or university network), contact your network administrator.

For detailed per-distribution firewall instructions, see the Firewall and Router Configuration page.

Step 3 — Forward the ports on your router (NAT)​

If your machine is behind a NAT router (the most common scenario for home users), the router must be configured to forward the three aMule ports to your machine's local IP address.

  1. Try UPnP first. Enable UPnP in aMule. If your router supports it, the ports are forwarded automatically and no manual configuration is needed.

  2. Otherwise, forward the ports manually. Open your router's web interface (usually at its LAN gateway address, e.g. http://192.168.1.1 or http://192.168.0.1) and log in. Look for a section named Port Forwarding, Virtual Servers, NAT, or LAN Configuration, and create three rules pointing to the LAN IP of the machine running aMule:

    ProtocolPortForward to
    TCP4662LAN IP of the aMule machine
    UDP4672LAN IP of the aMule machine (required for Kademlia)
    UDP4665LAN IP of the aMule machine (recommended)

  3. Use a fixed LAN IP. Assign a static IP to the aMule machine, or reserve its address via DHCP, so the forwarding rules don't break when the IP changes. If a Low ID reappears after a reconnect, check whether the LAN IP changed.

  4. Save and apply. You may need to restart the router.

After configuring, verify the ports are reachable using Testing your port status below.

Resources:

  • If your machine sits behind a Linux or BSD gateway that performs NAT, see Firewall and Router Configuration for nftables (Linux) and pf (OpenBSD) forwarding rules.
  • portforward.com provides walkthroughs for hundreds of consumer router models.
  • aMule supports UPnP, which can configure the router ports automatically if your router supports it.

Binding aMule to a network interface (VPN)​

If you run aMule over a VPN, set Preferences → Connection → Limits → Bind to network interface (the NetworkInterface key) to the VPN interface name (e.g. tun0, wg0, en0) or index; on Windows use the adapter's friendly name (e.g. Ethernet). Unlike Bind local address to IP, which only chooses the source address, this pins the traffic to the interface so it does not leave through the default route while the interface exists. Changing it requires restarting aMule. Not supported on BSD.

The binding covers all eD2k and Kademlia traffic (including connections through a proxy) and, on macOS and Linux where wxWidgets' curl backend is available, the HTTP downloads (server list, IP filter, GeoIP database, version check). It does not cover the UPnP traffic or the External Connections listener, which has its own setting in Preferences → Remote Controls.

If the interface does not exist, aMule logs WARNING: configured network interface '<name>' was not found … at startup. On some Linux kernels the binding needs the CAP_NET_RAW capability: grant it to the binary (e.g. sudo setcap cap_net_raw+ep /usr/bin/amule) instead of running aMule as root.

Not a kill switch

The binding fails open: if the interface does not exist or disappears later (for example, the VPN drops), aMule keeps working through the default route instead of stopping. If traffic must never leave outside the VPN, add a firewall rule that blocks aMule's traffic on every other interface, or use your VPN client's kill-switch feature.

IPv4 only​

aMule's network stack is IPv4 only: the hostnames it connects to (servers, the proxy, the External Connections host) are resolved to IPv4 addresses, so a name with only an IPv6 (AAAA) record cannot be used. localhost always means 127.0.0.1.

Server connection failures​

With Remove dead server after n retries enabled (the RemoveDeadServer and DeadServerRetry keys), servers that fail too often are removed from the list. aMule tries to count only the failures that are the server's fault:

  • Counted: the server refuses the connection, the operating system reports a connection timeout, the server's hostname does not resolve while other servers' hostnames do, and unanswered UDP pings (sent to the servers in the list while aMule is connected to one).
  • Not counted: errors that point to your own connection, such as network or host unreachable; aMule's own 25-second connection timeout; and a hostname that does not resolve when no other server's hostname resolves either (DNS is probably down).
  • Static servers are never removed.
  • When a whole pass over the server list fails, aMule waits 30 seconds before trying again, if Reconnect on loss is enabled in Preferences → Connection.

Kademlia connectivity (open vs firewalled)​

Kademlia uses "open" and "firewalled" instead of High ID / Low ID. Kad tracks the TCP port (4662) and the UDP port (4672) as separate states — the GUI shows them as Connection State (TCP) and UDP Connection State (UDP) in the Kad Info panel:

StatusMeaning
OpenBoth TCP 4662 and UDP 4672 are reachable. Full Kademlia participation as both a query target and a direct source.
FirewalledAt least one of the two ports is blocked or remapped. You remain connected to Kademlia and can still download, but participation is reduced: incoming connections are relayed through a buddy instead of reaching you directly.

When a port is firewalled, aMule looks for a buddy — an open Kad node that relays incoming connections (callbacks) on your behalf, so you stay reachable as a source even while firewalled. The buddy status is shown in the Kad Info panel, and the concept is explained in detail in Kademlia → Open vs. Firewalled Status.

NAT remapping of UDP 4672​

Some NAT routers perform port remapping: they change the source port of outgoing UDP packets to a different number. If your router remaps the source port of UDP packets sent from port 4672, other Kademlia nodes cannot reply to the correct port. The result is Kademlia reporting "firewalled" even when your TCP port is open and you have a High ID on eD2k.

aMule already tries to cope with this automatically: it asks several Kad nodes which source port they see, and if they agree on a remapped external port it uses that for its firewall check (preferring the internal port whenever a directly forwarded one is confirmed). The manual workaround below is for the cases where this automatic detection is not enough — typically when the router assigns an unstable external port that changes between packets.

Workaround:

  1. Choose a non-default port number n such that 80 < n < 65530 (some values known to work: 4811, 9870).
  2. In Preferences → Connection, set the Standard client TCP port to n.
  3. Forward the following three ports on your router:
    • TCP port n (instead of 4662)
    • UDP port n + 3 (instead of 4665)
    • UDP port 4672
  4. In Networks → Kad, update the node list and wait approximately 5 minutes.
  5. If Kademlia is still "firewalled", try a different value of n.

This often works because changing the TCP port also changes how the router handles the associated UDP traffic, which can stop it from remapping the source port.

Testing your port status​

Use one of these online port checkers to verify that your ports are reachable from the internet:

Enter each port number and run the check. These tools test generic TCP reachability — the most important check is your TCP port 4662 (or your configured TCP port), since that is what determines a High ID on eD2k. The results mean:

ResultMeaning
OpenThe port is reachable. With TCP 4662 open you should get a High ID on eD2k.
ClosedThe port is blocked by a firewall or not forwarded by your router. You will receive a Low ID.

UDP reachability (UDP 4672 for Kademlia, UDP 4665 for eD2k extended queries) is not reliably reported by generic port checkers, since UDP is connectionless. If TCP 4662 tests as open but Kademlia still shows "firewalled", see the Troubleshooting section below.

If port 4662 TCP shows "open" but you still receive a Low ID after connecting, the server you connected to may be overloaded or misconfigured — this is rare but possible. Try connecting to a different server.

Troubleshooting​

Low ID despite port 4662 being open​

  • Server overloaded or misconfigured. Some servers issue Low IDs to all new connections when under heavy load. Disconnect and reconnect to a different server.
  • ISP filtering port 4662. Some internet service providers block port 4662 on their network. Change your TCP port to a non-standard value (e.g. something between 1024 and 65535 that is not commonly blocked). Forward the new port on your router.
  • Double NAT. If your machine is behind two NAT routers (e.g. a home router connected to an ISP's own NAT gateway), port forwarding on your home router alone may not be sufficient. Contact your ISP.
  • Firewall on the machine. Ensure no local firewall (iptables, ufw, Windows Firewall, etc.) is blocking the port even after you opened it in the router.

Kademlia "firewalled" despite High ID​

  • NAT remapping UDP 4672 (see NAT remapping of UDP 4672 above).
  • UDP port 4672 not forwarded in your router, even if TCP 4662 is.
  • ISP filtering. Some ISPs filter both port 4662 and other P2P-associated ports. Changing to a custom port range usually resolves this.

Two clients both with Low ID cannot transfer​

This is a fundamental eD2k protocol limitation. There is no workaround other than getting at least one of the two clients to High ID status.