Proxy & network
A network route that belongs to the profile
Isolating the browser is half an environment. The other half is where its traffic comes out. PowerOps keeps proxies as a library, verifies them for real, and assigns them per profile.
eu-west-3.example.net:1080SOCKS5NetherlandsVerifieduk-lon-1.example.net:8080HTTPUnited KingdomVerifiedde-fra-2.example.net:3128HTTPSGermanyUncheckedsg-edge-7.example.net:1080SOCKS5SingaporeUnreachableus-east-4.example.net:8080HTTPUnited StatesUncheckedCountry is the address the test observed, not the location the provider listed.
Why the route belongs on the profile
A machine-wide proxy is a setting. A per-profile route is part of the environment.
A machine-wide proxy setting
- One proxy for the whole machine, changed by hand between tasks
- The endpoint written into each profile separately, and drifting
- No way to know an endpoint is dead until an account fails on it
- Credentials pasted into a URL field, and from there into a log
- Nothing to distinguish 'the proxy is down' from 'the site is blocking you'
With PowerOps
- A reusable library: enter an endpoint once, assign it to the profiles that need it
- Assignment copies the endpoint onto the profile, so no two profiles share one live credential
- Verification before an account ever touches it, showing the address actually observed
- Bulk assignment, so fifty profiles can be moved to a new endpoint in one action
- Network status in the header, so an outage looks like an outage rather than a bug
How a route reaches a browser
- 1
Add the endpoint once
Host, port, protocol and, if it needs them, a username and password all go in separate fields. The host field rejects anything that looks like a URL, a credential or a malformed address, because those are the inputs that later become incidents.
- 2
Verify it before you trust it
Test one endpoint or the whole list. PowerOps connects through it and reports the outbound address and country actually observed, or names the specific way it failed.
- 3
Assign it to profiles
Assignment copies the endpoint onto each profile. The browser is launched behind that route for its whole session, with the credential handled inside that profile's own directory and removed when it stops.
Verification
Failures are named, not shrugged at
A test that only says 'failed' tells you to try again. These say what to do.
Unreachable
The endpoint did not answer at all.
Authentication failed
It answered and rejected the credentials.
DNS failed
The proxy could not resolve the name it was asked for.
TLS failed
The secure handshake did not complete.
Timed out
It answered too slowly to be usable.
Configuration invalid
The endpoint as entered cannot be used.
The lookup itself has its own named failures. That keeps “we could not check” from ever being reported as “your proxy is broken”.
What the proxy library does
Structured, not stringly
Endpoints are stored as fields. A proxy URL, which mixes the password into the endpoint, is never how PowerOps holds one.
Credentials out of the database
Passwords go to the OS credential store, or a 0600 file where there is none. The app tells you which one it used.
Redacted everywhere
A proxy password is never returned by a query endpoint, never logged, never on a command line.
Per-profile auth
Authenticated proxies are handled inside the profile's own directory, and the material is deleted when the browser stops.
Recent endpoints
The ones you actually use stay one click away when creating the next profile.
Bulk operations
Verify a whole list, or move many profiles to a new endpoint, in one action.
Proxies, answered
Does PowerOps sell proxies?
No. There is no bundled proxy pool, no country list to buy from and no reseller margin in this product. You bring endpoints from a provider you chose, and PowerOps manages, verifies and assigns them.
Which protocols are supported?
HTTP, HTTPS and SOCKS5, with or without a username and password, over IPv4 or IPv6. HTTP CONNECT and SOCKS5 verification are implemented directly, so a test measures the protocol a profile will actually use.
How are proxy passwords stored?
As structured fields. A proxy URL mixes the password into the same string as the endpoint, which is how passwords end up in logs, so PowerOps never holds one that way. The password itself goes to the operating system's credential store, or to a 0600 file in a 0700 directory where none is available, and the application says plainly which of the two it is using.
Can a password leak through the API or a process list?
A proxy password is never returned by a query endpoint, never written to a profile row, never put in audit metadata, and never placed on a command line. Authenticated proxies are handled through a minimal extension generated inside that profile's own directory and deleted when the browser stops, so two profiles cannot share auth material.
What does a verification actually check?
That the endpoint accepts a connection, that the credentials are accepted, and what outbound address is observed on the other side. A proxy-level failure stops there rather than being retried against a second lookup service. Retrying an authentication rejection is how accounts get locked.
Give every profile its own way out
Bring your own provider. PowerOps manages, verifies and assigns the endpoints.