# Device HTTP Proxy

FIRERPA provides an HTTP proxy on the phone (the bridging proxy in service configuration, i.e., `tunnel2.*`). When you point your computer or browser's proxy server to the phone, computer traffic to websites will first go through the phone and then exit from the phone's network, so the external IP appears the same as the phone's. It is the opposite of [Setting Proxy](./set-proxy.md), as compared below:

| | **Device HTTP Proxy** (this chapter) | **Setting Proxy** |
| --- | --- | --- |
| **Network Direction** | **Computer** → via **phone** to the internet | **App on phone** → via **external proxy** to the internet |
| **Typical Use** | Allow the computer to use the phone's IP | Assign a proxy IP to the phone |

Common uses include letting a computer and phone share the same egress IP for joint debugging and troubleshooting, pointing mitmproxy's upstream to the phone when capturing traffic so that traffic still originates from the device, or using multiple devices' networks as IP sources.

## Using the Proxy

This feature is enabled by default. The proxy shares the same service port as remote desktop, defaulting to `65000`. Check the current IP in the phone's WLAN settings (the example below uses `192.168.0.2`). If you have changed the `port`, please replace the port in the examples accordingly. The computer must be able to access the phone's FIRERPA service port, which usually means being on the same LAN or forwarding the service port to the public network.

You can quickly verify with the following command on the computer (replace the IP with your device's address):

```bash
curl -x http://192.168.0.2:65000 https://httpbin.org/ip
```

If the returned IP matches the phone's external IP, it is working correctly. In Firefox, you can set the HTTP proxy to `192.168.0.2`, port `65000`, and check "Also use this proxy for HTTPS". In Python, you can write:

```python
requests.get("https://httpbin.org/ip", proxies={"http": "http://192.168.0.2:65000", "https": "http://192.168.0.2:65000"})
```

When the service certificate is not enabled, the proxy requires no authentication by default. If you started with a service certificate, you need to use the username `lamda` and the password from the first line of the service certificate PEM file (the same as the HTTPS remote desktop login password, but not the WebUI custom password). You can also set `tunnel2.password` in [Service Configuration](./properties.md) to specify a separate proxy password. In this case, the curl example becomes:

```bash
curl --proxy-insecure -x https://lamda:cert-password@192.168.0.2:65000 https://httpbin.org/ip
```

And the Python example:

```python
requests.get("https://httpbin.org/ip", verify=False, proxies={"http": "https://lamda:cert-password@192.168.0.2:65000", "https": "https://lamda:cert-password@192.168.0.2:65000"})
```

## Configuring the Proxy

You can adjust the bridging proxy in [Service Configuration](./properties.md). For example, set `tunnel2.login` and `tunnel2.password` to customize the login credentials:

```ini
tunnel2.login=lamda
tunnel2.password=your-new-password
```

`tunnel2.iface` specifies the egress network interface: `wlan` for Wi-Fi, `rmnet` for mobile data (4G/5G; even if Wi-Fi is connected, mobile data will be preferred). When not configured, the system default network is used. If the selected interface currently has no network, the proxy will be unavailable.

```ini
tunnel2.iface=rmnet
```