localhost/DVWA Not Working? Complete Troubleshooting Guide

If localhost/DVWA is not working, do not reinstall DVWA immediately. In most cases, the problem is much simpler: the wrong URL, an incorrect folder location, Apache not running, a missing configuration file, or a database connection issue.

The most important thing to understand is that http://localhost/DVWA/ is not the correct address for every DVWA installation.

If you installed DVWA with XAMPP or a traditional Apache web server, an address such as localhost/DVWA is normal. However, the current official Docker Compose installation uses:

http://localhost:4280

The official DVWA documentation currently tells Docker users to start the application with docker compose up -d and access it through port 4280.

This troubleshooting guide will help you identify exactly why DVWA is not opening and fix the problem without making unnecessary changes.

Security note: DVWA is intentionally vulnerable. Keep it on localhost or another isolated lab environment. The DVWA project recommends local loopback access as the safe default rather than exposing the application publicly.

Quick Answer: Why Is localhost/DVWA Not Working?

If localhost/DVWA is not opening, first identify how you installed DVWA.

Installation	Typical URL
Official Docker Compose	`http://localhost:4280`
XAMPP with folder named `DVWA`	`http://localhost/DVWA/`
XAMPP with folder named `dvwa`	`http://localhost/dvwa/`
Folder left as `DVWA-master`	`http://localhost/DVWA-master/`
Apache with `/var/www/html/DVWA`	`http://localhost/DVWA/`
Docker with custom port	`http://localhost:YOUR-PORT`

If you used Docker and are trying:

http://localhost/DVWA/

try this instead:

http://localhost:4280

If you used XAMPP and localhost/DVWA returns a 404, check whether the actual DVWA files are located directly inside:

C:\xampp\htdocs\DVWA

These two checks solve a large percentage of DVWA localhost problems.

What Does localhost/DVWA Mean?

localhost refers to your own computer.

When you open:

http://localhost/

your browser connects to a web server running locally instead of connecting to a website somewhere on the Internet.

The /DVWA/ part normally represents a directory underneath your web server’s document root.

For example, XAMPP commonly serves files from:

C:\xampp\htdocs

If DVWA is located at:

C:\xampp\htdocs\DVWA

the corresponding address is normally:

http://localhost/DVWA/

This is why simply downloading DVWA is not enough. Your web server must know where the DVWA files are located.

localhost/DVWA vs localhost:4280

This distinction is the first thing every DVWA user should understand.

XAMPP and Traditional Apache

A traditional web-server installation places DVWA inside Apache’s document root.

For example:

C:\xampp\htdocs\DVWA

corresponds to:

http://localhost/DVWA/

On Linux, you might have:

/var/www/html/DVWA

which similarly becomes:

http://localhost/DVWA/

Docker Compose

The official DVWA Docker Compose setup works differently.

Its current compose.yml contains this port mapping:

127.0.0.1:4280:80

This means port 4280 on your computer connects to port 80 inside the DVWA container.

So Docker users should normally open:

http://localhost:4280

rather than:

http://localhost/DVWA/

The official README explicitly documents this address.

Start With This 60-Second DVWA Check

Before changing configuration files, work through these checks in order.

Identify your installation method. Is it Docker, XAMPP, or manual Apache?
Try the correct URL. Docker normally uses localhost:4280; XAMPP commonly uses localhost/DVWA.
Check the server. Apache or Docker must actually be running.
Check the DVWA files. Make sure index.php, setup.php, and the config directory exist.
Check config.inc.php. Manual installations need the active configuration file.
Check the database service. MariaDB/MySQL must be running.
Read the actual error. A 404, blank page, error 1045, and connection refused all mean different things.

Do not apply a database fix to a 404 error or reinstall Apache because of an incorrect password. Diagnose first.

localhost/DVWA Shows 404 Not Found

A 404 Not Found usually means Apache is running, but the URL does not match the location of your DVWA files.

The official DVWA troubleshooting documentation specifically recommends checking where DVWA was installed relative to the web-server document root and checking the capitalization of the directory name when a 404 appears.

Check the XAMPP Folder

On a standard Windows XAMPP installation, look inside:

C:\xampp\htdocs

You want a structure similar to:

C:\xampp\htdocs\DVWA

Inside DVWA, you should see files such as:

index.php
login.php
setup.php

Then open:

http://localhost/DVWA/

If those PHP files are not directly inside that folder, your URL may not match your directory structure.

Your DVWA Files Are One Folder Too Deep

This is a very common problem after extracting the DVWA GitHub ZIP file.

You may accidentally have:

C:\xampp\htdocs\DVWA\DVWA-master\index.php

while trying to open:

http://localhost/DVWA/

Your actual application is one directory deeper.

A cleaner structure is:

C:\xampp\htdocs\DVWA\index.php

Move the actual DVWA contents into the DVWA directory, or use the URL that matches your real directory structure.

Your Folder Is Still Named DVWA-master

When you download the GitHub master branch as a ZIP archive, the extracted directory may be named:

DVWA-master

That name is not an error. It simply reflects the Git branch from which the archive was downloaded.

If you place that directory directly inside XAMPP:

C:\xampp\htdocs\DVWA-master

then the URL may be:

http://localhost/DVWA-master/

You can make the address easier to remember by renaming the directory to:

DVWA

and then using:

http://localhost/DVWA/

DVWA Works With /DVWA but Not /dvwa

Capitalization matters especially on Linux.

These two names can represent different directories:

DVWA

and:

dvwa

If your application is installed at:

/var/www/html/DVWA

open:

http://localhost/DVWA/

The official troubleshooting documentation identifies directory case as one of the things to check when DVWA returns a 404.

localhost Opens XAMPP or Apache Instead of DVWA

Seeing the XAMPP dashboard or Apache default page is actually useful information.

It means the web server is probably working.

If:

http://localhost/

opens successfully but DVWA is stored in:

C:\xampp\htdocs\DVWA

you need to include the directory name:

http://localhost/DVWA/

There is normally no reason to reinstall Apache in this situation. The issue is simply the URL or document path.

“This Site Can’t Be Reached” or “localhost Refused to Connect”

This error is different from a 404.

A 404 means a web server answered your browser but could not find the requested page. Connection refused often means nothing is listening on that address or port.

If you are using XAMPP, open the XAMPP Control Panel and verify that Apache is running.

Then test:

http://localhost/

If that page also fails, fix Apache before troubleshooting DVWA itself.

Apache Will Not Start in XAMPP

If Apache cannot start, another application may already be using the port it needs.

Common possibilities include another web server, IIS, another Apache installation, or another local development tool.

Instead of changing random settings, open the Apache logs from XAMPP and identify the actual port conflict.

If Apache is configured to use a non-standard port, your URL also needs that port.

For example:

http://localhost:8080/DVWA/

The exact address depends on your Apache configuration.

Docker DVWA Does Not Open

If you used Docker Compose, first check whether the containers are actually running.

Open a terminal in the DVWA directory and run:

docker compose ps

If the environment is stopped, run:

docker compose up -d

Then open:

http://localhost:4280

The current official Docker instructions use this exact workflow.

Docker Says compose.yml Cannot Be Found

Docker Compose must be run from the directory containing the Compose file.

If you cloned DVWA with Git:

git clone https://github.com/digininja/DVWA.git

enter the repository:

cd DVWA

Then run:

docker compose up -d

The official installation instructions specifically tell users to change their working directory into the DVWA folder before running Docker Compose.

localhost:4280 Is Not Working

If you are using Docker and localhost:4280 does not respond, start by checking:

docker compose ps

Then read the logs:

docker compose logs

The official troubleshooting guide recommends docker compose logs for inspecting the combined logs from the DVWA environment.

You can also inspect a specific service:

docker compose logs dvwa

or:

docker compose logs db

The logs may immediately reveal whether the web container or database container failed.

Port 4280 Is Already in Use

Another application may already be using port 4280.

The current DVWA documentation allows you to change the port mapping in compose.yml.

The default is:

ports:
  - 127.0.0.1:4280:80

For example, you can change it to:

ports:
  - 127.0.0.1:8806:80

Restart the environment:

docker compose down
docker compose up -d

Then use:

http://localhost:8806

This custom-port approach is documented by the official project.

Keep 127.0.0.1 unless you have a specific controlled-lab reason to change the network exposure.

DVWA Says “Config File Not Found”

A manual installation may show an error similar to:

DVWA System error - config file not found.

The DVWA source checks for:

config/config.inc.php

and instructs users to create it from:

config/config.inc.php.dist

when it is missing.

Copy:

config.inc.php.dist

and rename the copy:

config.inc.php

Your config directory should then contain both files.

Windows Created config.inc.php.txt

Windows sometimes hides known file extensions.

You may think your file is:

config.inc.php

while it is actually:

config.inc.php.txt

DVWA will not recognize that as its PHP configuration file.

In Windows 11, open File Explorer and enable:

View → Show → File name extensions

Then confirm the file is exactly:

config.inc.php

The official DVWA documentation specifically warns Windows users about hidden file extensions when creating the configuration file.

DVWA Shows a Blank White Page

A blank page often means PHP has encountered an error but is not displaying the message.

The official DVWA troubleshooting guide describes this as one configuration problem hiding another. For example, a database connection may fail, but if PHP error display is disabled, you only see an empty page.

Enable these PHP settings in your development environment:

display_errors = On
display_startup_errors = On

Save php.ini, restart Apache, and reload DVWA.

Once PHP displays the underlying error, troubleshooting becomes much easier.

Restart Apache After Changing php.ini

Changing PHP configuration does not automatically mean Apache is using the new setting.

After editing php.ini, restart Apache.

On XAMPP:

Open XAMPP Control Panel.
Stop Apache.
Start Apache again.

The official DVWA documentation explicitly tells users to restart PHP or Apache after changing PHP configuration values.

DVWA Database Is Not Connecting

Once the page itself loads, the next common group of problems involves MariaDB or MySQL.

For a standard manual installation, the current DVWA configuration template defaults to settings including:

Server: 127.0.0.1
Database: dvwa
User: dvwa
Port: 3306

The project also uses a dedicated database account rather than recommending the MariaDB root account.

If DVWA cannot connect, compare the values inside:

config/config.inc.php

with the database account you actually created.

Do not edit config.inc.php.dist and assume DVWA will use it. The application expects config.inc.php.

Database Error #1045: Access Denied

If you see something similar to:

Database Error #1045:
Access denied for user

the database username or password configured in DVWA does not match the real database credentials.

The official troubleshooting guide identifies error 1045 as a credentials problem.

Check these values:

$_DVWA[ 'db_server' ] = '127.0.0.1';
$_DVWA[ 'db_database' ] = 'dvwa';
$_DVWA[ 'db_user' ] = 'dvwa';
$_DVWA[ 'db_password' ] = 'p@ssw0rd';
$_DVWA[ 'db_port' ] = '3306';

Your actual database account must match the configuration.

The specific password above is the current default value in the DVWA configuration, but if you created a different password, use your own value consistently.

Database Error #1044: User Has No Permission

Error 1044 is different from error 1045.

With error 1044, the login credentials can be valid, but the account does not have permission to use the requested database.

The official project describes it this way: credentials are correct, but the user cannot access the database.

Check:

The database really is named dvwa.
The correct database user is being used.
That user has privileges on the DVWA database.

Do not keep changing the password when the actual problem is database authorization.

Database Error #2002

Error 2002 usually means DVWA cannot reach the database server.

The official troubleshooting guide states that this is not an authentication problem and commonly means the database server is not running.

On XAMPP, check the database service in the XAMPP Control Panel.

On Linux, check MariaDB/MySQL.

For example:

systemctl status mariadb

If the database is stopped, start the correct service for your operating system.

DVWA Says “Connection Refused”

A PHP database error containing:

Connection refused

usually indicates that the database is stopped or that DVWA is trying to connect to the wrong database address.

The official DVWA documentation identifies these as the primary causes.

For a normal manual installation, check:

$_DVWA[ 'db_server' ] = '127.0.0.1';

For Docker Compose, the situation is different. The official Compose configuration passes:

DB_SERVER=db

because the application container talks to the MariaDB container using Docker’s internal service name.

Do not blindly copy manual XAMPP database settings into Docker.

localhost vs 127.0.0.1 for the Database

Your browser can use:

localhost

while your database configuration uses:

127.0.0.1

These are not contradictory.

The official DVWA config file specifically notes that users experiencing database connection problems can try 127.0.0.1 instead of localhost because it can avoid socket-related connection issues.

For the standard manual configuration, 127.0.0.1 is currently the default.

Create / Reset Database Is Not Working

DVWA provides its own setup page.

For an XAMPP installation stored in a folder named DVWA, it is commonly:

http://localhost/DVWA/setup.php

The setup page contains a Create / Reset Database button.

The official source explains that this button creates or resets the DVWA database and recommends checking config.inc.php credentials if the operation fails.

If it does not work, check these items:

Apache is running.
MariaDB/MySQL is running.
config.inc.php exists.
Database username and password are correct.
Database name is correct.
The database account has sufficient privileges.
Required PHP database extensions are available.

This is a situation where a checklist is more useful than reinstalling everything.

Be Careful With Create / Reset Database

The reset button is not just a connection test.

The current setup page warns that if the database already exists, its DVWA data will be cleared and reset. It can also reset the administrator credentials to the defaults.

Use it when you want a fresh DVWA lab or when the database has not yet been initialized.

Do not use it casually if you need to preserve your existing DVWA lab data.

DVWA Login Is Not Working

The current official DVWA documentation lists the default application login as:

Username: admin
Password: password

If these credentials do not work after a fresh installation, the database may not have been initialized correctly.

Open the setup page and confirm that database creation succeeded.

If you intentionally reset the database, the setup source confirms that the default administrator credentials can also be restored.

Setup Page Shows Red Warnings

The DVWA setup page checks more than just the database.

It can report the status of PHP, writable directories, Apache features, and optional functionality.

Do not assume every red item means the entire DVWA installation is broken.

For example, current DVWA uses:

mod_rewrite

for its API labs. The official setup source specifically says mod_rewrite is required for those API labs.

If your classic DVWA labs work but an API-related requirement is missing, troubleshoot that feature separately rather than reinstalling the entire application.

File Upload Directory Is Not Writable

DVWA’s File Upload lab needs a writable directory.

The official configuration documentation lists:

./hackable/uploads/

as a directory that must be writable by the web service.

If the setup page reports a permissions problem, check the file permissions and ownership for that specific directory.

Avoid applying overly broad write permissions to your entire web root just to fix one folder.

File Inclusion Lab Is Not Working

Some DVWA lab behavior depends on PHP settings.

The official documentation lists these settings for Remote File Inclusion functionality:

allow_url_include = On
allow_url_fopen = On

If you change these values, restart Apache.

These settings belong in an intentionally vulnerable local training environment. They should not be treated as recommended production PHP settings.

Your PHP Version Is Too Old

An outdated XAMPP or manually installed PHP version can produce unexpected DVWA problems.

The current DVWA documentation recommends using the latest stable PHP version. It says PHP 5.x is unsupported and that versions below PHP 7.3 have known problems.

If you are following a very old DVWA tutorial with an equally old XAMPP package, update the environment instead of trying to force current DVWA to work with obsolete PHP.

API Lab Is Not Working

The API portion of current DVWA has additional requirements that old DVWA tutorials may not mention.

The official project currently requires Apache mod_rewrite for the API lab and also requires Composer-installed vendor dependencies.

If the main DVWA interface works while the API module fails, the overall installation may be fine.

Check API-specific requirements rather than rebuilding everything.

Docker Starts DVWA Automatically

You may stop DVWA only to find it running again after Docker restarts.

This is not necessarily an error.

The current Compose file includes:

restart: unless-stopped

for the services.

Temporarily stop the lab with:

docker compose stop

or remove the containers with:

docker compose down

The official documentation also explains that the automatic restart behavior can be changed in compose.yml.

Docker Database Keeps Old Data After Reinstalling

Docker stores the database in a named volume.

The current DVWA Compose file defines a database volume that is mounted into MariaDB.

That means removing and recreating the containers does not necessarily create a completely fresh database.

If you intentionally want to remove the Compose containers and their stored volume, you can use:

docker compose down -v

Then start again:

docker compose up -d

Be careful: deleting the volume removes stored DVWA database data.

Browser Keeps Showing an Old DVWA Error

Sometimes the server has been fixed but the browser still has an old redirect, cookie, or cached response.

Try a private/incognito window first.

You can also clear only the DVWA site’s cookies and cached data rather than deleting your entire browser history.

If the problem happens in multiple browsers, the cause is more likely to be server-side.

localhost Works but DVWA Does Not

This is a useful diagnostic clue.

If:

http://localhost/

works but:

http://localhost/DVWA/

does not, your web server itself is probably functioning.

Focus on:

DVWA directory location
Folder name
Capitalization
Nested directories
index.php
Configuration files

Do not reinstall XAMPP just because one application directory is wrong.

phpMyAdmin Works but DVWA Does Not

If:

http://localhost/phpmyadmin/

works, you already know Apache and at least part of your database environment are functioning.

Focus on DVWA itself:

Does config.inc.php exist?
Are database credentials correct?
Does the dvwa database exist?
Can the configured user access it?
Does the setup page load?
Are PHP errors visible?

Troubleshooting becomes easier when you eliminate components that are already working.

DVWA Loads but One Lab Does Not

If you can log into DVWA and most pages work, do not troubleshoot it as a complete installation failure.

Individual labs may depend on specific PHP settings, writable directories, Apache modules, or additional dependencies.

For example:

File Upload requires writable storage.
Remote File Inclusion depends on specific PHP settings.
API labs require mod_rewrite and Composer dependencies.

Troubleshoot the individual lab requirement instead.

XAMPP DVWA Troubleshooting Checklist

If you installed DVWA with XAMPP on Windows, work through this sequence.

Check Apache

Open XAMPP Control Panel and confirm Apache is running.

Check the Database

Make sure the database service is also running.

Test localhost

Open:

http://localhost/

Test phpMyAdmin

Open:

http://localhost/phpmyadmin/

Check DVWA Location

Confirm the files are directly inside something like:

C:\xampp\htdocs\DVWA

Check the Main PHP File

Confirm:

C:\xampp\htdocs\DVWA\index.php

exists.

Check the Configuration

Confirm:

C:\xampp\htdocs\DVWA\config\config.inc.php

exists.

Open the Setup Page

Try:

http://localhost/DVWA/setup.php

Initialize the Database

Use Create / Reset Database if this is a new lab or you intentionally want to reset it.

Log In

Try:

http://localhost/DVWA/login.php

with the current default application credentials.

This order allows you to discover exactly where the installation stops working.

Docker DVWA Troubleshooting Checklist

For the official Docker Compose setup, use a different diagnostic flow.

First, check Docker itself:

docker version

Then check Compose:

docker compose version

Enter the DVWA directory:

cd DVWA

Start the environment:

docker compose up -d

Check the containers:

docker compose ps

If something looks wrong, inspect the logs:

docker compose logs

Finally, open:

http://localhost:4280

This matches the current official Docker workflow.

Linux Apache DVWA Troubleshooting Checklist

For a traditional Linux installation, first confirm Apache and MariaDB are running.

For example:

systemctl status apache2

and:

systemctl status mariadb

Check whether DVWA is under the Apache document root, commonly something similar to:

/var/www/html/DVWA

Then confirm the URL capitalization matches the folder.

Apache logs are also valuable. The official DVWA troubleshooting documentation notes that Debian-based systems commonly store access.log and error.log under:

/var/log/apache2/

Logs often tell you more than the browser does.

DVWA Error Reference Table

Error or symptom	Most likely area to check
`404 Not Found`	Wrong folder or URL
Apache/XAMPP homepage	Missing `/DVWA/` path
Site cannot be reached	Apache/Docker not running
`localhost:4280` fails	Docker containers or port
Blank white page	Hidden PHP error
Config file not found	Missing `config.inc.php`
Error 1045	Wrong DB username/password
Error 1044	DB permissions or wrong database
Error 2002	Database server unavailable
Connection refused	DB stopped or wrong address
Login fails	Database initialization/account state
File Upload warning	Directory permission
API lab error	`mod_rewrite`/Composer requirements
Old data after Docker restart	Persistent Docker volume

Use the symptom to decide which section to troubleshoot rather than applying every possible fix.

Best Troubleshooting Order for Beginners

When DVWA is broken, there is a logical order that saves time.

First: Check the URL

Determine whether you should be using:

http://localhost/DVWA/

or:

http://localhost:4280

Second: Check the Web Server

Apache or Docker must be running before anything else matters.

Third: Check the Files

Make sure DVWA is in the correct directory and not nested one folder too deep.

Fourth: Check config.inc.php

Manual installations need the active configuration file.

Fifth: Check the Database

Confirm the database server is running and the configured credentials are correct.

Sixth: Reveal PHP Errors

A blank page becomes much easier to fix once PHP tells you what failed.

Seventh: Read Logs

Use Apache logs or:

docker compose logs

Last: Reset or Reinstall

Only reset the database or reinstall the environment after you understand the problem.

That troubleshooting order is both faster and safer than repeatedly reinstalling DVWA.

Should You Reinstall DVWA?

Usually, no.

Most DVWA problems are configuration problems rather than damaged installations.

Reinstallation makes sense when files are missing, the download is incomplete, you used the wrong project copy, or you intentionally want to rebuild the lab.

It should not be your first response to:

A 404
Wrong database password
Port conflict
Missing config file
Stopped Apache service
Wrong URL

Fix the specific problem first.

How to Prevent localhost/DVWA Problems

Once your lab works, a few habits make future troubleshooting easier.

Keep your folder name simple, such as:

DVWA

Save the correct address for your installation.

For XAMPP:

http://localhost/DVWA/

For current Docker Compose:

http://localhost:4280

Keep your database credentials consistent between the actual database account and config.inc.php.

Most importantly, read error messages before changing configuration. Error 1045, error 1044, a 404, and connection refused all describe different problems.

Frequently Asked Questions

Why is localhost/DVWA not working?

The most common causes are the wrong URL, Apache not running, DVWA being outside the web-server document root, incorrect folder capitalization, a missing config.inc.php, or database connection problems.

Start by identifying whether you installed DVWA with Docker or XAMPP.

What is the correct DVWA localhost URL?

For a typical XAMPP installation with a DVWA folder:

http://localhost/DVWA/

For the current official Docker Compose installation:

http://localhost:4280

The Docker address is documented in the current official README.

Why does localhost/DVWA show 404?

Apache can normally be reached, but it cannot find a DVWA path matching your URL.

Check the directory location, folder name, capitalization, and whether your source files are nested inside another directory. The official troubleshooting guide specifically recommends these checks for 404 errors.

Why does localhost show XAMPP instead of DVWA?

You opened the root web-server address:

http://localhost/

If DVWA is inside htdocs\DVWA, open:

http://localhost/DVWA/

instead.

Why does localhost/DVWA not work with Docker?

The official Docker Compose environment does not normally use a /DVWA subdirectory in the browser URL.

Open:

http://localhost:4280

instead.

Why does localhost:4280 not work?

Check:

docker compose ps

and:

docker compose logs

The containers may not be running, the application may have failed to start, or port 4280 may already be occupied.

Where should DVWA be installed in XAMPP?

A typical Windows location is:

C:\xampp\htdocs\DVWA

Your main PHP file should then appear directly at:

C:\xampp\htdocs\DVWA\index.php

Why is config.inc.php missing?

DVWA distributes a template called:

config.inc.php.dist

Create the active file from that template:

config.inc.php

The application explicitly requires the active file.

Why does DVWA show a blank white screen?

PHP may have encountered an error while error display is disabled.

Enable:

display_errors = On
display_startup_errors = On

restart Apache, and reload DVWA. This is the troubleshooting approach recommended by the official project.

What does DVWA Error 1045 mean?

Error 1045 normally means the username or password in the DVWA database configuration does not match the database account.

What does DVWA Error 1044 mean?

Error 1044 means the account is accepted but does not have permission to access the requested database.

What does DVWA Error 2002 mean?

Error 2002 normally means the database server is not running or cannot be reached.

Why does DVWA say “Connection refused”?

The official troubleshooting guide says this usually means the database server is stopped or the configured database address is wrong.

Should DVWA use localhost or 127.0.0.1 for the database?

The current manual configuration defaults to:

127.0.0.1

and the config template notes that this can avoid certain socket-related problems associated with localhost.

What are the default DVWA login credentials?

The current official documentation lists:

Username: admin
Password: password

Will Create / Reset Database delete DVWA data?

Yes.

The current setup source warns that an existing DVWA database will be cleared and reset.

Why is mod_rewrite showing as missing?

Current DVWA requires Apache mod_rewrite for its API labs. If you are specifically trying to use the API section, enable and configure that dependency.

Should I reinstall XAMPP if DVWA is not working?

Usually not.

If http://localhost/ works, Apache is already serving pages. Check the DVWA path, folder structure, configuration file, database, and PHP errors before reinstalling XAMPP.

Final Thoughts

When localhost/DVWA is not working, the best solution is to diagnose the layer that actually failed.

If you installed DVWA through XAMPP or a traditional Apache setup, your address may be:

http://localhost/DVWA/

If you installed DVWA through the current official Docker Compose setup, the normal address is:

http://localhost:4280

From there, follow a simple troubleshooting path:

Correct URL
↓
Apache or Docker status
↓
DVWA folder and files
↓
config.inc.php
↓
Database service
↓
Database credentials
↓
PHP errors
↓
Server logs

Remember what the major errors tell you.

A 404 usually points to the wrong path or directory.

A blank white screen often hides a PHP error.

Error 1045 points to database credentials.

Error 1044 points to database permissions.

Error 2002 usually means the database server is unavailable.

And if Docker works but /DVWA does not, you may simply be using the wrong address—the current official Docker setup uses localhost:4280.

Most DVWA localhost problems can be solved without reinstalling the entire environment. Identify the symptom, fix the specific layer, and keep the application isolated as a local security-training lab.