Same story as the `appengine` error: urllib3 2.0 removed `DEFAULT_CIPHERS`, which this code imports at load. Pin urllib3 to the 1.26 line (`python -m pip install 'urllib3==1.26.15'`) and the import works. This usually arrives via cfscrape, which cloudscraper superseded.

## The error

```text
ImportError: cannot import name 'DEFAULT_CIPHERS' from 'urllib3.util.ssl_'
```

## Fix it

1. **Pin urllib3 to 1.26**

```
python -m pip install 'urllib3==1.26.15'
```
Expected: pip installs urllib3 1.26.15.

2. **Confirm the import**

```
python -c "import cloudscraper; print('ok')"
```
Expected: prints `ok`.

3. **If the traceback names cfscrape instead, migrate**

cfscrape is dead upstream. Replace `import cfscrape` with cloudscraper's `cloudscraper.create_scraper()` API, which handles the same Cloudflare challenges and is maintained.
Expected: the scraper works without the removed-name import.

## When this applies

- the ImportError names `DEFAULT_CIPHERS` from `urllib3.util.ssl_`
- the traceback goes through cfscrape or old cloudscraper code
- it broke after a urllib3 upgrade to 2.x

## When it does NOT apply

- `cannot import name 'appengine'` is the sibling removal, same pin fixes both
- `No module named 'cloudscraper'` is the missing install

## Compatibility

urllib3 2.x removed DEFAULT_CIPHERS. urllib3 1.26.15 still has it. cfscrape-era code only works on the 1.26 line.

## Why it happens

urllib3 2.0 removed several internal helpers that scraping libraries had been importing, DEFAULT_CIPHERS among them. Code written against urllib3 1.x imports them unconditionally at module load, so the import dies before any request is ever made. The 1.26 pin restores every removed name at once.

## Edge cases

- You will often see this AND the appengine error in the same env. One pin fixes both because both names only exist on the 1.26 line.
- If something else in the env hard-requires urllib3>=2, split the scraper into its own venv. There is no version of urllib3 that has both the new API and the removed names.