skip to content

In Selenium 4, what port does Grid's standalone server listen on by default?

level: juniorimportance: should knowfreq 74%

answer

  1. It is the number you already type locally
  2. One digit, repeated four times
  3. A short flag and a long flag move it
  4. The root path and /wd/hub both answer
  5. The standalone command's own flag default

basics

~10 s

Port 4444. A Selenium 4 server started with the standalone command serves WebDriver on http://localhost:4444, at both the root path and /wd/hub, and the -p or --port flag moves it.

solid answer

~40 s

A Selenium 4 server started with the `standalone` command listens on port 4444 by default, so a timetable-board suite points at `http://localhost:4444`. The same server also answers on the `/wd/hub` prefix, kept from Selenium 3 so older configuration still resolves, and both paths reach the same WebDriver routes. Change the port with `-p` or `--port`, which is how two standalone servers run on one machine. The 4444 default belongs to the standalone command itself: the generic server layer underneath would otherwise pick any free port. `--host` and `--bind-host` govern which address the server reports and binds, and `/readyz` is a plain readiness endpoint worth polling before the suite starts.

code

bash · 3 lines
bash
java -jar selenium-server.jar standalone --port 4444 &
java -jar selenium-server.jar standalone --port 4455 &
wait

go deeper

for a junior

Recall the number and the flag: a standalone Selenium 4 server answers on port 4444, and -p or --port moves it. Knowing that http://localhost:4444 is what a suite points at is the expected screening answer.

for a middle

Explain where that default comes from and what else the listener carries: the same port serves the root path and /wd/hub, so both URLs reach identical WebDriver routes inside one process.

for a senior

Treat the port as an operational detail you have handled. Two servers on one host need two ports, a runner has to expose the one it uses, and a readiness probe should gate the suite instead of a fixed sleep.

for a principal

Own the convention rather than the number. Decide whether every team gets its own standalone server on the default port or shares one, and publish that as the default so nobody invents a topology per project.

## The number, and where it comes from A **Selenium 4** server started with the `standalone` command listens on **port 4444**. That is why the getting-started instructions tell you to point a suite at `http://localhost:4444` without configuring anything, and why a team building a **train timetable board** suite can get from a downloaded jar to a working remote endpoint in one command: ```bash java -jar selenium-server.jar standalone ``` Three things are easy to conflate here, so separate them: - The **jar** is the Selenium server download; `standalone` is a subcommand you pass to it, not a file name. - The **port** belongs to that server process. It is not a browser's port and not a driver's port. - The **URL** a suite points at is that port plus a path, and the server answers on two paths. The default is not a property of HTTP, and it is not chosen by the operating system. It is a **flag default declared by the standalone command itself**, which contributes a `port` value of `4444` in the server configuration section. The generic server layer underneath behaves differently: asked for a port with nothing configured, it finds any free one. So 4444 is predictable precisely because `standalone` asked for it. The same number is the documented default for the other Grid roles that act as an entry point, which is why people associate 4444 with the grid in general. ## Both doors reach the same routes The listener on 4444 serves the WebDriver routes at **two paths**: - **`/`**, the root — the canonical address in Selenium 4, and what a bare `http://localhost:4444` resolves to. - **`/wd/hub`**, a prefix mounted onto exactly the same routes. It exists for compatibility with configuration written in the **Selenium 3** era, when a hub's WebDriver endpoint lived under that path. Both work. Neither is faster, safer or more capable, and a board suite that has always said `/wd/hub` keeps working after an upgrade. New configuration should use the root URL, because the `/wd/hub` shape implies a claim — that there is a hub somewhere — which is not true of a single-process server. | You point at | It reaches | Reason to use it | |---|---|---| | `http://localhost:4444` | the WebDriver routes | it is the Selenium 4 address | | `http://localhost:4444/wd/hub` | the same WebDriver routes | an older configuration already says so | ## Moving the port Two spellings of one flag do it: `-p` and `--port`. ```bash java -jar selenium-server.jar standalone --port 4455 ``` Reasons a real team needs it: 1. **Two servers on one machine.** Only one listener can hold 4444, so a second standalone server — one for the board suite, one for something else — needs its own port. 2. **The port is already taken,** often by an earlier standalone server left running in another terminal. Once a port has been configured the server does not quietly move to another; it fails to bind. 3. **A host convention.** Some CI runners and container hosts reserve ranges, and the server has to fit what is available. ## The neighbouring flags on the same listener - `--host` sets the IP or hostname the server reports for itself; without it, the server works one out. - `--bind-host` controls whether the server actually binds that name or only uses it to report a reachable URL. - `--external-url` sets the URL other parties should use, for network shapes where the reachable address differs from the bound one. - `--allow-cors` decides whether browser-originated connections from any host are accepted, and it is off by default. None of these change the default port; they change what the server says about itself at that port. ## Checking it is up before the suite runs A standalone server exposes `/readyz`, which answers `200` with `Standalone is true` once its internal parts report ready and `503` before that. It is deliberately reachable even when the server is protected by basic authentication, so a probe can always use it: ```bash until curl -sfo /dev/null http://localhost:4444/readyz; do sleep 1; done ``` The failure this prevents is a familiar one on a timetable-board pipeline: the first specification fails with a connection error, everything after it passes, and somebody spends an afternoon blaming the board instead of the start-up race.

  • What happens if port 4444 is already taken when you start the standalone server?
    It fails to bind rather than quietly moving elsewhere, because a port has been configured and the server uses the one it was given. Pass a different one with `--port`, or stop whatever holds 4444, which is often an earlier standalone server started in another terminal and never shut down.
  • Why does a Selenium 4 standalone server still answer on /wd/hub?
    For compatibility with configuration written in the Selenium 3 era, when a hub's WebDriver endpoint lived under `/wd/hub`. Selenium 4 mounts the same router at the root and at that prefix, so both work and neither is preferred. New configuration should use the root URL, since there is no hub in a single-process server.
  • Can two suites share one standalone server on the same port?
    Yes. One server holds several sessions at once, so two suites can both use `http://localhost:4444` and each get its own browser, up to what the machine offers. They are not isolated from one another, though, which is why a CI job normally starts a server of its own instead.

saying these in an interview costs you the question

  • Says a standalone server has no default port and must always be given one
  • Thinks the port can only be changed by editing a configuration file
  • Believes /wd/hub is required and the bare root URL does not work
  • Assumes every browser session needs its own standalone server and port
  • Confuses the Selenium server's port with a browser driver's own port