Enable Remote MySQL Connections in cPanel

Remote MySQL connections are disabled by default in cPanel servers because they are considered a potential security threat. Using the tools in the Web Host Manager (WHM) and the domain-level cPanel interface (usually http://domainname.com/cpanel) remote hosts can be added which the server allows to connect to the MySQL service.

Before using either of the following techniques, you will need to to open up port 3306 in your server’s firewall.

Enabling Remote MySQL in the WHM Interface

Log in to the server’s WHM interface and find the section in the left-side navigation bar labeled SQL Services. You can sort the list by typing ‘sql’ in the search box. Click on the link marked Additional MySQL Access Hosts:

WHM - Remote MySQL List

On the following page, enter one or more hosts or IP addresses in the text box (1) and click the Save button (2). If you wish to activate these settings on all user accounts see (3).

WHM - Remote MySQL page

Now that the remote connection has been activated in the WHM each domain account that wants to use the remote connection will need to activate it in their own cPanel interface.

Enabling Remote MySQL in the Domain cPanel Interface

Log in to the domain’s cPanel interface and find the section on the main page labeled Databases.

In the Databases section find the link/button labeled Remote MySQL and click on it.

cPanel - Remote MySQL list

The following page will appear in your browser. Add a hostname or IP address that you want to grant remote MySQL access to (1) and then click the Save button (2).

If a host or IP address needs to be removed from this list you can click the ‘Delete’ button next to the entry in the list.


Once you have made your changes, additions, or removals to the list you can return the main page of the cPanel interface, or log out if you have no other tasks to take care of.


Liquid Web’s Heroic Support is always available to assist customers with this or any other issue. If you need our assistance please contact us:
Toll Free 1.800.580.4985
International 517.322.0434

Featured Freeware: MTR

Featured Freeware highlights some of the Liquid Web staff’s favorite free software. This week we are covering a treasured favorite, MTR.

Note: This post assumes you have a working knowledge of traceroute.

MTR (originally Matt’s Traceroute, now My Traceroute) functions like traceroute insofar as it displays the network hops from your local machine (or server, depending on where you run the command) to the target IP address or hostname.

But MTR differs from traceroute by constantly observing and displaying the network hops and related statistics instead of displaying a single set of results. Put simply, if you traceroute to google.com you will get a report for a single connection from your computer to Google’s servers. If you MTR to google.com you will see a continuously updated display of each hop and its performance over time until you tell it to stop. Response times can be evaluated just like traceroute or ping results: Higher numbers are bad, lower numbers are good. If a particular hop is showing much higher response times than the others, even without packet loss, you can see that it might be having a problem.

MTR can be installed on almost any Linux machine by using a local package manager such as yum or apt. Windows and Mac OS X users can install MTR using the links in the Additional Resources section at the bottom of this post.

Basic MTR Usage

Example MTR command from a Liquid Web server to google.com:

[root@host]# mtr google.com

My traceroute [v0.85]
host.example.com ( Wed Mar 23 14:58:34 2016
Keys: Help Display mode Restart statistics Order of fields quit
  Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 0.0% 461 1.1 1.1 1.0 14.9 0.7
2. router.example.com 0.0% 461 1.1 2.0 1.0 156.2 0.6
3. router2.example.com 0.0% 461 1.1 10.7 0.9 197.3 32.2
4. border.example.com 0.0% 461 29.2 32.2 7.1 271.5 38.6
5. eqix-ch-100g.google.com 0.0% 460 9.0 7.6 7.1 28.3 0.4
6. 0.0% 460 7.3 8.2 7.3 30.7 2.3
7. 0.0% 460 7.3 7.6 7.3 25.6 1.5
8. ord31s21-in-f14.1e100.net 0.0% 460 7.3 7.6 7.2 20.5 1.5
Note: This represents a static screen from an MTR result, but when run in this manner MTR will continuously update these stats until you cancel it with CTRL+C or q. Alternatively, if you really want a static report instead of a realtime analysis, you can use mtr with the –report flag to generate a summary report: “mtr –report google.com”

Breaking the results down from left to right:

  • Host: The name or IP address of the network hop.
  • Loss%: The percentage of packets that are being lost during the trace. In most cases, this is the first result you want to watch.
  • Snt: The number of packets sent to the hop.
  • Last: The response time of the last packet sent to the hop.
  • Avg: The average response time during the entire span of the test.
  • Best: The best response time during the entire span of the test.
  • Wrst: The worst response time during the entire span of the test.
  • StDev: Is the Standard Deviation of latencies to the host, and can help you better evaluate the average latency measurement. A high StDev indicates an inconsistency in the latency measurements on that hop, such as when a wide gap is recorded between the best and worst latencies on that hop.

Evaluating MTR Results

Almost immediately you will want to pay attention to the Loss% column in MTR’s display. As the tests progress, the percentage will get more accurate at telling you where there may be a problem. Generally speaking, you will see packet loss at every hop past the point of trouble if a network issue is in play, and the point in the route at which the packet loss occurs will narrow down the nature of the specific issue.

  • Depending on your home or office network setup, the first hops likely will be your local firewall and/or router or wireless access point. If the packet loss is occurring in one of these first couple of hops, it could be an indicator of trouble within your local network. You may want to try temporarily disabling the firewall or antivirus suite on your computer and checking the route (and the site) again.
  • The next hop likely will be your Internet Service Provider’s network, and you may recognize your ISP’s name in the host column. If the packet loss is here, then you have a strong indicator that your ISP is having problems on their end. Do other websites load properly, or is everything slow?
  • Packet loss in the middle of the route can be an indication of a problem with a major Internet route. In this case, you can notify your ISP and they can potentially contact their upstream provider to get the matter resolved. It is important to note, however, that some packet loss at this stage is normal: You can almost always expect to see minor packet loss when the server is physically located in a different geographic region or across a large body of water, such as an ocean. The amount of packet loss typically will increase with distance. If the route continues past this point and ultimately connects to the server, there may be not be a network issue. To confirm, you can test the route to the site from a server in the same geographic region as your server using a free tool such as Traceroute Tools Online or through a free VPN service. If there are no issues, you may want to consider using a Content Delivery Network to ensure that the bulk of your site’s resources are served from the locations closest to your site visitors.
  • Finally, the route will pass through your hosting provider’s router and firewall to reach their internal network, and then through your server’s firewall (which may be a cloud firewall, a hardware firewall, a software firewall, or a combination of the three). If you’re a Liquid Web customer, follow the instructions in our article at Unblocking an IP Address in the Firewall or use our semi-automated IP address unblock tool in Manage to ensure that your IP address is not being blocked in your server’s firewall.

Additional Resources