What Is a Virtual Machine? Setup, Networking, and Proxy Configuration

Quick Answer

A virtual machine is a software-defined computer that runs a guest operating system through a hypervisor while using the host's physical CPU, memory, storage, and networking. Use one when a task needs a separate OS or reproducible test environment. A VM does not automatically change the public IP websites see; that depends on its network path and any proxy configured for the application.

A VM, Browser, and Proxy Solve Different Problems

These layers can be combined. For example, a QA engineer can run an Ubuntu guest on a Windows host, create an isolated Playwright browser context in the guest, and configure that context to use a country-targeted proxy. Each layer still has a different job.

A host is the physical computer and operating system providing the resources. A guest is the operating system running inside the VM. The hypervisor creates the virtual hardware presented to the guest and maps its work to the host's actual hardware.

In a typical desktop VM:

• Virtual CPU (vCPU) represents processing capacity scheduled on the host's CPU.
• Virtual RAM is host memory reserved for the guest while it runs.
• Virtual disk is usually a file on the host that the guest sees as a disk drive.
• Virtual network adapter connects the guest through NAT, bridged, host-only, or another configured network mode.
• Guest operating system runs its own kernel, system services, users, and applications.

Oracle VirtualBox is a hosted, or type-2, hypervisor: it runs as an application on the host operating system. Server platforms can instead use a type-1 hypervisor that runs closer to the hardware. This guide uses VirtualBox for a practical desktop setup. The headless browser guide covers browser automation without the VM layer.

When Should You Use a VM?

A VM is appropriate when the task benefits from a separate operating-system environment rather than only a separate browser tab or dependency folder.

Useful examples include:

• Testing another operating system. A developer on Windows can test an application in Ubuntu without replacing or dual-booting the host OS.
• Isolating dependencies. One guest can keep a specific browser, runtime, library, and system configuration without changing the host.
• Reproducing browser or network issues. A support or QA team can preserve a known guest image and repeat the same environment.
• Running a separate automation worker. A VM can give a browser job its own OS processes, filesystem, resource limits, and recovery point.
• Creating a disposable lab. Snapshots make it easier to return a test guest to an earlier state, although snapshots are not a replacement for backups.

A VM may be unnecessary when a virtual environment, container, or browser context provides enough separation. More isolation also means more memory, storage, maintenance, and startup time.

Do You Need a VM, Container, or Browser Context?

Choose the smallest boundary that satisfies the task.

Docker's container overview explains that ordinary containers share the host kernel. A VM runs a guest kernel. The options are not mutually exclusive: containers often run inside a VM, including on desktop container platforms and cloud infrastructure.

Does a Virtual Machine Have a Different IP Address?

A VM commonly has a different private address from the host but the same public exit address on the internet.

The two addresses answer different questions:

• A private or local IP identifies the VM within a virtual or physical local network. Examples include addresses in 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16.
• A public IP is the internet-facing address observed by an external website after local NAT, an ISP gateway, a company gateway, a VPN, or a proxy has routed the connection.

With VirtualBox's default NAT mode, the flow normally looks like this:

The guest may show a private address such as 10.0.2.15, while an IP-checking website shows the same public upstream address seen from the host. That is expected. The private address proves that the guest has a virtual network interface; it does not prove that the guest has a separate internet identity.

VM Networking: NAT, Bridged, and Host-Only

Networking is the part of VM setup most likely to cause confusion. Oracle's VirtualBox networking documentation describes several modes. These three cover most desktop tests.

For the underlying address-translation model, see how NAT works.

NAT Mode

NAT is VirtualBox's default and the simplest mode for this walkthrough. The guest receives a private address on a VirtualBox-managed network. VirtualBox resends outbound traffic using the host's networking facilities.

NAT is a good starting point when the guest only needs outbound web access. It does not normally make the VM visible as a separate machine to the physical LAN, and inbound services require explicit port forwarding.

Bridged Mode

Bridged mode attaches the VM to the physical network as another LAN participant. The VM may receive its own LAN address from the network's DHCP server and can be subject to the same local firewall and access-control rules as another device.

A distinct LAN address still does not guarantee a distinct public address. On an ordinary home or office network, the router may translate both the host and VM through the same public IP. Some Wi-Fi adapters, managed networks, and corporate policies also restrict bridged behavior.

Host-Only Mode

Host-only mode creates a network between the host and selected guests without connecting that network to the public internet by default. It is useful for an isolated test lab or for services that only the host should reach.

If the guest requires both an isolated lab interface and internet updates, an administrator can add a second adapter with NAT. That design creates two network paths, so firewall rules and service bindings need careful review.

Does Changing the Network Mode Change the Country Websites See?

Usually not. NAT and bridged mode change how the guest reaches the local network. The country seen by a website is normally derived from the public egress IP. If both modes ultimately use the same ISP or organization gateway, the visible country will generally remain the same.

Use a separate authorized network path, VPN, or proxy when the task requires a particular public exit location. Then verify the result inside the exact application performing the test.

How to Set Up a VM for Browser Testing

The walkthrough uses the following example configuration so the steps and resource advice have a clear scope. It is a reproducible setup template, not a report of a completed benchmark.

The allocation is a starting point for this example, not a universal VM requirement. Ubuntu's current desktop installation guide calls for at least 25 GB of storage. Oracle advises leaving enough CPU and memory for the host and not assigning more than half of the host's processor threads. Increase the guest allocation only when its workload and the host's available resources justify it.

1. Download the Hypervisor and Guest ISO

Download VirtualBox from Oracle's official site and the Ubuntu Desktop 24.04 LTS ISO from Ubuntu. Select the VirtualBox installer for the host's operating system and processor architecture. Verify downloads using the checksums or signing information provided by the vendors where available.

Oracle's VirtualBox installation guide and Ubuntu's desktop download page should be the sources of truth for current packages.

2. Create the VM

In VirtualBox Manager:

1. Select New.
2. Give the VM an informative name, such as ubuntu-browser-test.
3. Select the downloaded Ubuntu ISO.
4. Choose either the supported unattended installation or disable it to use Ubuntu's interactive installer.
5. Allocate 2 vCPUs and 4 GiB of RAM for this reference setup, provided the host can spare them.
6. Create a 30 GiB dynamically allocated virtual disk.
7. Finish the workflow, but review the network and sharing settings before starting the guest.

Oracle's Create a New Virtual Machine guide explains the current VirtualBox 7.2 interface. Available choices can differ by host architecture and selected guest OS.

3. Select NAT Networking

With the VM powered off:

1. Open Settings for the VM.
2. Open Network.
3. Enable Adapter 1.
4. Select NAT under Attached to.
5. Leave additional adapters disabled for the first test.

Starting with one network path makes the observation easier to interpret. Capture a screenshot of this setting for the test record.

4. Install and Update Ubuntu

Start the VM and follow Ubuntu's installer. After the guest reaches its desktop, open Terminal and apply available updates:

Restart the guest if the update process requires it.

5. Review Host-Guest Integration Features

VirtualBox Guest Additions can improve display resizing, mouse integration, shared clipboard, drag and drop, and shared folders. Those conveniences also create additional paths between host and guest.

Keep shared clipboard, drag and drop, USB passthrough, and shared folders disabled unless the test needs them. If a shared folder is necessary, expose only the required directory and permissions. Oracle's VirtualBox Security Guide specifically warns that shared clipboard and shared folders weaken the separation between host and guest.

Keep VirtualBox, the host OS, the guest OS, and Guest Additions updated. Guest Additions should match the installed VirtualBox version where possible.

6. Confirm Direct Internet Access

Inside Ubuntu, inspect the guest's local address:

Then open the guest browser and visit the Proxidize IP Checker. Record the visible public IP, country, city, ISP or organization, and test time. Repeat the same check from the host browser.

With this reference NAT setup, the host and guest will often show different private addresses but the same public upstream IP. Record what actually happens rather than treating that pattern as guaranteed.

How to Configure a Proxy Inside the VM

Configure the proxy at the narrowest scope that matches the test. A browser-level or browser-context proxy is easiest to reason about because its effect is explicit.

Do not enter proxy details in VirtualBox Manager and assume the guest browser will use them. VirtualBox network modes and an application proxy are different controls.

Install Playwright in the Ubuntu Guest

Inside the guest, create a Python virtual environment and install Playwright with Chromium:

Playwright officially supports HTTP(S) and SOCKS5 proxy configuration at browser or browser-context scope. This example uses an authenticated HTTP endpoint because the username and password fields are explicit.

Run a Direct and Proxied Browser Check

Save the following complete script as vm_network_check.py. It prompts for the proxy values instead of embedding credentials in source code. It opens the same IP-check endpoint once without a proxy and once with the configured proxy, saves screenshots, writes a local JSON record, and flags a mismatched country or unchanged public IP.

Run it from the activated virtual environment:

Enter the HTTP proxy server, username, password, and expected country generated for the access point. A server value should include the scheme and port, such as http://proxy.example.com:12345. Do not publish or commit the real credentials.

The IP-check endpoint is an independent diagnostic service, not part of Proxidize. If it returns an error or a questionable location, repeat the check with another trusted service and compare it with the proxy provider's usage record. IP geolocation databases can disagree, so a city result should be treated as evidence to investigate rather than an absolute physical-location measurement.

The complete Playwright proxy guide covers Python, Node.js, authentication, browser-context proxies, sticky sessions, and rotation in more detail.

Reader Checklist: Verify the VM and Proxy Network Path

The public IP must be checked from the application whose route matters. A successful curl command in the guest does not prove that a browser uses the same proxy, and a successful host-browser check does not prove anything about the guest browser.

Use this sequence:

1. Record the host browser's public IP and country without the proxy.
2. Record the guest browser's public IP and country in NAT mode without the proxy.
3. Run the Playwright script inside the guest and record its direct observation.
4. Let the script create a new browser using the Proxidize proxy and record its proxied observation.
5. Confirm that the proxied IP differs from the direct IP and that the observed country matches the requested country.
6. Confirm corresponding traffic or usage in the provider dashboard where available.
7. Repeat with an intentionally incorrect proxy password. Confirm that the request fails visibly and that you do not observe a successful direct fallback during that check.

Use this checklist to retain the evidence from your own setup:

Mask credentials, account identifiers, and personal IP addresses before sharing the evidence. The completed checklist describes one configuration and one set of observations; it does not prove that every VM, host network, proxy, or website behaves identically.

Where Proxidize Fits

A direct connection is sufficient when the test only needs a separate guest OS and does not require a different public route or location. Adding a proxy introduces another dependency, so it should solve a defined requirement.

Proxidize is relevant when the application inside the VM needs a managed exit IP, a particular location, or rotating or sticky proxy-session behavior. Proxidize Residential Proxies provide global country, city, and ISP targeting across 195+ countries. Proxidize Mobile Proxies are the better fit when a workflow specifically needs a real US mobile-carrier route.

The VM still supplies the guest environment. Playwright still supplies the browser automation and browser-state boundary. Proxidize supplies the configured network route. It does not make the VM inherently anonymous, replace browser/session handling, or guarantee access to a destination.

Use Proxidize only for lawful testing, monitoring, and data collection, and ensure the workflow complies with applicable law and third-party terms.

Is a Virtual Machine Safe?

A VM can reduce direct interaction between guest applications and the host, but it is not a guarantee that no harm can reach the host. Hypervisor vulnerabilities, guest-to-host integration features, exposed network services, insecure files, stolen credentials, and configuration mistakes can all reduce the boundary.

Use these controls for a browser-testing guest:

• Keep the host OS, hypervisor, guest OS, browser, runtime, and Guest Additions updated.
• Disable shared clipboard, drag and drop, shared folders, USB passthrough, and remote access unless required.
• If file exchange is necessary, share the minimum directory and permissions.
• Use NAT for simple outbound testing unless the guest genuinely needs a LAN presence.
• Apply a guest firewall and do not expose unnecessary services.
• Store proxy credentials outside source code, logs, screenshots, and VM images distributed to others.
• Treat snapshots as convenient rollback points, not complete backups.
• Do not assume a VM makes unknown or malicious software safe to run.

Oracle's Security Guide states that virtualization provides containment but cannot offer a perfect guarantee. Security decisions should reflect the workload's risk, not the convenience of restoring a snapshot.

Common VM and Proxy Problems

For a broader diagnostic process, see how to test a proxy.

Final Verdict

A virtual machine is worth using when a task needs a separate guest operating system, kernel, filesystem, dependency set, or reproducible desktop environment. It is more isolation than a browser context and more overhead than a container or virtual environment.

Use VirtualBox NAT as the simple starting point for an outbound browser-testing guest. Do not confuse the guest's private IP with its public internet exit. Add a proxy only when the application needs a defined route, location, or session policy, and verify that route from inside the same application.