How to set up port mapping on a Mercury router? Connecting to the home NAS on foreign networks always fails, but melogin.cn can be solved in five steps

last Friday during my lunch break at the company, a colleague wanted to see the National Day aerial footage of my NAS at home. I took out my phone and typed my home address, spinning around, but couldn't get in. My Mercury D191G at home runs fine, and Feiniu NAS is always accessible on the internal network. Why does it turn hostile as soon as I step outside? It took me half an night to figure it out: the router defaults to all external knocks, so to access home devices from outside, you have to manually open a small window—this is port mapping, and the Mercury backend calls it a "virtual server." I explained the principles of port forwarding and DMZ in another article , and this one article focuses on one thing: how to configure it on a Mercury router, and how to check if it doesn't work.

first check which interface your Mercury is on—the entrance is completely different

I've had three Mercury routers in my hands, with two interfaces and a wide difference in the entry, so I matched the number before I started.

new cloud router : can log into MERCURY ID, the homepage is card-style, I have the D191G, and the MER1200G I bought for my parents are all included. Connect your phone or computer to its WiFi, enter melogin.cn browser (192.168.0.1 works too, same portal), log in, tap 'Advanced Settings' in the top right corner, then drag the menu to 'Advanced Users' on the left, and you'll see 'Virtual Server'. By the way, DMZ host and UPnP settings also live in the same menu, which I'll discuss later.

old : a black background with a row of text menus, MAC1200R machines from that era. The entry point is in 'Forwarding Rules' → 'Virtual Server', then click 'Add New Entry'. The menu names are different, but the contents are exactly the same.

method is quite basic: log in and check the homepage; cards with large images of connected devices are the new interface; A row of dropdown text menus is the old interface. One more reminder: it's normal not to be able to find port mapping in the Mercury WiFi App. This feature is exclusive to the web backend. I have already listed the remote management tasks the app can do remotely. If you can't even open the melogin.cn, don't rush to suspect the router is broken. I've written about five common domain login pitfalls separately, sorted in that order.

five steps plus one rule, four fields filled in like this

the interface is correct, all that's left is to fill out a small form. Take the new interface as an example:

Step one: Connect your phone to Mercury's WiFi—changing the background app requires the person to be online; remote changes are not possible. Step two: Enter melogin.cn browser to log in. Step 3: Advanced Settings → Advanced User → virtual server, click "Add." Step four: Fill in the four fields. Step 5: Click Save. The rule takes effect immediately, no need to restart the router.

four fields are the highlight of this article. I'll go through them one by one:

External port : The house number used to knock on the external network. Home Broads' ports 80 and 443 are basically blocked by carriers. If you just want to save trouble and enter 80, no matter how well you match, you won't connect. Use high-level ports above 10000; I'm used to 18080 and 28080, which are easy to remember and less likely to run into batch scans.

Internal Port : The port where the device is actually running at home. My Feiniu NAS management page is 5244. Just fill in the port of your service, don't copy me. For common cases, I made a table:

IP address : Enter the internal IP of the device at home. I entered 192.168.0.108. This section is the most popular pitfall, which will be discussed in the next section.

protocol : For web pages and management pages, just select TCP; Gaming online and some monitoring push UDP; If you really can't tell the difference, choose ALL. This option is available on the Mercury interface, allowing full protocol release, so it's fine for home use.

one thing before you start: tie static IP

My first white match trip ended up falling here. The IP in the rules is set to death. Today, the NAS uses 192.168.0.108, and when the DHCP lease expires, after restarting tomorrow, it changes to 109. The rules are still eagerly forwarding traffic to 108—an address where no one lives. The rules clearly didn't get it wrong, but no matter what, it just wouldn't connect. This kind of silent loss is the hardest to detect.

solution is to keep the device's IP untouched. Two binding methods: one is manual binding on the device side. NAS and surveillance devices support manually specifying IP, subnet mask, gateway, and DNS in their own settings. I prefer this method as it's the most stable; Second, the router side has address retention. If your Mercury interface has this feature, bind the device's MAC and IP tightly for the same effect. general practice for static IP binding I wrote an article covering the tips of picking addresses outside DHCP's range—just copy it.

: first bind the IP, then add the rules. If you do it the other way, what awaits you is the kind of mysterious disconnection mentioned above.

setup but can't connect? Check in this order, don't rush to delete the rules

the rules are set, just type 'public IP:18080' at the company, and you're still spinning in circles. Don't doubt whether you made a mistake yet. Go through it in this order, and I'll rank it from highest to lowest by the number of failures:

First, check if your test posture is correct. testing the public address by connecting to your home WiFi is an invalid test—you're on the internal network, the data packet hasn't even left the premises, and it's still going directly to the internal network. Turn off your phone's WiFi, check the data again, and that's what counts. The first time I made a mistake here, the rules were fine, but the test method was wrong.

second, check what IP the router's WAN port is used. check the WAN port IP on Mercury's status page, and this string of numbers directly determines what you do next:

check if you have a complete method for using a public IP address, including the scripts for calling carriers, I have written a dedicated . I've written about the mapping operations at the optical modem layer in Tianyi Gateway version If you find dual-layer mapping troublesome, just convert the optical modem to a bridge it's all done. Once Mercury takes over the dial-up, it's a complete layer.

third check: the port itself. some regional operators, even the high-level port is blocked on the field end. If 18080 doesn't work, switch to 28080 and try again. If neither works, it's basically determined to be the exit side. Also, make sure the external and internal ports are not filled in correctly—external department plate 18080, internal implementation 5244, don't get the direction wrong.

Fourth check: Device Firewall. people at home and type 192.168.0.108:5244 in their computer browser, and if they get in, it means the service itself is fine—the problem lies in the link; If you can't get in, it's a NAS issue. Feiniu has a switch like 'LAN access only,' and if Synology Firewall doesn't allow access, external sources are still rejected. This step helps you separate the "router's pot" from the "device's pot."

two neighbors in the same menu: UPnP and DMZ

in the advanced user menu, there are two functions next to the virtual server. I'll explain them clearly so you don't have to open them randomly.

UPnP: Let the device request the router to open the door itself. The NAT type required for PS5 and Switch online and BitTorrent are all automatically mapped by it. Mercury's path is set by advanced users → UPnP settings → turned ON. For home use, I suggest keeping the map running for convenience. After opening it, remember to occasionally check the mapping list, so don't let apps that shouldn't open the door stuff you with a bunch of rules—where to read fair risk statements and mapping lists, UPnP explained everything thoroughly.

DMZ: Bring all ports of a device to the external network bare. I only turned it on for ten minutes to check NAS connectivity—once the link was confirmed, it turned off immediately. Forgetting to check this thing comes at a high cost—a typical case of a weak password camera being scanned. In short, the relationship among the three is: virtual server precisely opens a door, UPnP means the device opens its own door, and DMZ is the that tears down an entire wall.

don't have a public IP, don't fight for it—there are two fallback options

if the second check reveals you're CGNAT, you won't be able to call the public IP (some regions really don't need it). Don't argue with port mapping—take a different approach.

one is IPv6. Currently, the three major carriers issue IPv6 by default. On Mercury, turn on v6 (I've written about the switch location and three pitfalls). If your phone also has v6 on the data side, just use the v6 address to connect to your home device, skipping port mapping. Just make sure the firewall lets you through ports.

another is internal net penetration. FRP self-built and official NAS relays (Synology QuickConnect, Feiniu fn Connect) all work. The speed ceiling is a bit lower, but zero public IP requirements and configuration are hassle-free. comparison of three remote routes calculated before.

the end: first bind static IPs, then add rules, verify mobile traffic data, don't check WAN port IPs, and finally IPv6 or penetration as a backup. Port mapping is a one-time connection that solves the problem once and for all; when it fails, it's almost certainly Mercury's fault—it's the public IP sabotaging the way.