Accessing DirectAdmin Panel

By default DirectAdmin is listening only on port 2222, so, the access URL would be:


Running a second port for non-secure connections

There could be various reasons you might need a non-secure (plaintext) connection to DA. One is if you have a very old OS which doesn't speak the newer openssl versions, where the newer boxes no longer speak the old ones (really, your old box should be replaced with a more modern OS that supports newer openssl versions).

If you decide to use this method, we'll assume you still want SSL/https on port 2222, but will have a 2nd non-secure connection for ports 2223.

  1. Add or change the /usr/local/directadmin/conf/directadmin.conf these settings to provided below:

Where the plaintext port uses SSL=0 and port=2223, and the setting "ssl_port=2222" defines a 2nd port for secure connections, which is going to be the main one used for most things.

  1. In case it's not obvious, making connections over a plaintext connection is not secure and packets could be sniffed. Although it's not perfect, at a minimum, you'll want to be using the Login Key to allow dns to be copied around, but you should also restrict it to a given IP address, so in the even that the packet is sniffed and the login key is obtained, they could only use it by logging into the remote DA box from that specified IP address. See Example C

  2. It would also be recommended to setup your firewall on the remote server to only accept connection to port 2223 from that restricted client IP address.

  3. An extra measure (may be tricky for novices) to use iptables on the client server to only allow outbound connections to that remote box if the User is "nobody" (this likely needs to be done by someone experienced with your firewall). This is not tested, but an example on how to only allow "nobody" and root to access remote servers on port 2223:

$IPTABLES -A OUTPUT -m owner --uid-owner nobody -p tcp --dport 2223 -j ACCEPT
$IPTABLES -A OUTPUT -m owner --uid-owner root -p tcp --dport 25 -j ACCEPT

The example would be inserted into your general iptables rules, but would likely need some tweaking depending on which firewall you're running.

Running DA service through apache on port 80

Several people are unable to connect to DirectAdmin on port 2222 due to firewalls or proxies. It is possible to setup Apache to allow DirectAdmin to run through Apache using its proxy options.

In this example, we'll setup DirectAdmin to run through with server IP . Type your server's .


With the custom template system, we can add sufficient overrides to not need to make any changes to the templates themselves.

  1. First, create the domain under a User level, as a full domain somewhere. This will allow you to setup SSL with LetsEncrypt very easily.
  2. Next, go to Admin Level -> Custom HTTPD Configuration -> and in the top |CUSTOM| token textarea, insert:
|*if SSL_TEMPLATE="1"|
       ProxyRequests off
       SSLProxyEngine on

       ProxyPass /phpmyadmin !
       ProxyPass /phpMyAdmin !
       ProxyPass /webmail !
       ProxyPass /roundcube !

       ProxyPass / ""
       ProxyPassReverse / ""
       #ProxyPreserveHost On
       RewriteEngine On
       RewriteCond %{HTTPS} off
       RewriteCond %{REQUEST_URI} !^/.well-known
       RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
  1. Set a proper client IP logging:
cd /usr/local/directadmin
./directadmin set x_forwarded_from_ip ""
service directadmin restart

NOTE: The above assumes that you've setup SSL for your hostname with this guide , so that the actual :2222 access matches, in the Proxy settings above. Because is a User Level domain, it cannot be your , so they'll probably be different.


LiteSpeed is slightly different in terms of using the ProxyPass option. For new method A, step 2, use the following instead:

|*if SSL_TEMPLATE="1"|
      RewriteEngine On
      #RewriteCond %{REQUEST_URI} !^/?(phpmyadmin|phpMyAdmin|webmail|roundcube|)/
      RewriteRule ^(.*)$ https://cp.|DOMAIN|:2222/$1 [P,L]
      RewriteEngine On
      RewriteCond %{HTTPS} off
      RewriteCond %{REQUEST_URI} !^/.well-known
      RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Note, LiteSpeed dose not allow proxying to just any value. You if you get this in the error.log:

[REWRITE] Proxy target is not defined on external application list, please add a 'web server' with name ""

then you'll need to add an approved proxy web server in your LSWS panel Admin > Configuration -> Server -> External App -> Add for each host that will connect to DA. Should we find some way to override the "Host" value sent to LSWS from the redirect, then the value in the template could be unified, saving the need to load up everyone's cp.|DOMAIN| in the LSWS admin area. You'll also need to hit the "graceful reload" option after changing things.


Edit the /etc/nginx/nginx-includes.conf file and add:

server {
   listen "";
   server_name "";

   include /etc/nginx/webapps.conf;

   location / {
       proxy_pass       "";
       proxy_set_header Host $host;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_redirect "" "";

Restart nginx:

service nginx restart


If you're still unable to login run DA in debug mode, level 2000.

    Checking referer "" to ""
    Referer port (443) does not match DA's (2222): ""
In which case, you'd need to disable the port during the referer checks:

Actively testing a DirectAdmin connection

By default, the dataskq will make sure that the "directadmin" process is running. You can take it a step further if you'd like to confirm that DA is responding and a user/pass is working correctly.

  1. First, create a login key for a sample DirectAdmin account. Set: Key Name: curltest Key Value: Random Expires On: Never Uses: 0 Commands: Allow: CMD_API_LOGIN_TEST Allowed IPs: and enter your current password to create the key. The long string on the next page will be the password you'll use below.

  2. Type in your:
    Login Key:

  3. Edit the script /home/username/ and paste in the code:

#DEBUG=0 normal running after settings confirmed
#DEBUG=1 basic output during testing to confirm settings
#DEBUG=2 raw output to see what's going on



echo -n '' > ${CONFIG}
echo "user = \"${USER}:${PASSWORD}\"" >> ${CONFIG}

RUN="curl --config ${CONFIG} --silent --show-error"

if [ "${DEBUG}" -ge 2 ]; then
       eval $RUN
       #stderr to cron output
       RESULT=`eval $RUN 2>&1`
       COUNT=`echo "$RESULT" | grep -c 'error=0'`
       if [ "${COUNT}" -gt 0 ]; then
               if [ "${DEBUG}" -ge 1 ]; then
                       echo "all is well";
               exit 0;
               if [ "${RET}" -eq 0 ]; then
                       echo "Unable to verify login. Try DEBUG=2";
                       echo "curl returned code 0, so is likely a user/pass issue";
                       exit 1;
                       echo "$RESULT";
                       echo "curl returned code ${RET}";
                       exit ${RET}

Make it executable:

chmod 700 "/home/username/"

NOTE: If you're running DA with https, change http to https in the RUN variable. Same applies if you're not using port 2222, adjust the port there.

  1. Manually run the script to see if it work:
"/home/username/"; echo $?

If you see '0' as the output, that's a good thing. Set DEBUG to 1 or 2 to help sort out any issues.

  1. Once you confirm it is working, create a cronjob under the username account DA panel > User Level > CronJobs Leave all time values as *, but set the command to be:

and do not press the "Prevent E-Mail", or else you won't get any notices.

  1. On the same Cronjobs page, type in your E-Mail in the "Send all Cron output to E-Mail" section. Check that account for any emails containing output if DA is not running.
Last Updated: