Open the Web UI at
http://safesquid.cfg/ from a machine that can reach the appliance. Policy lives in the Web UI; process tunables live in startup.ini.What you will set up
- Confirm the service is running
- Confirm how clients reach SafeSquid (listen address)
- Lock down who may use the proxy (Access restrictions)
- Point a browser at the proxy and test
- Add a simple content rule (Access Profiles)
- Learn where to look when something fails (logs)
1. Confirm the service
On the appliance:/etc/init.d/safesquid start. Details: Daemon, service, and files.
2. Confirm listen address
In the Web UI open Network settings → Listen.- You should see at least one enabled listener (IP and port), often port 8080.
- If Listen is empty, SafeSquid falls back to
LISTEN_IP/LISTEN_PORTin startup.ini.
3. Lock down Access restrictions
Open Access restrictions. This is the security perimeter: who may connect and what they may do.- Set Default Access Policy to Deny (recommended).
- Leave Kerberos / SSO off for this first pass (add it later; see Authentication).
- Add one Allow list entry for your office or lab network.
4. Point a browser and test
- On a PC inside the allowed range, set the HTTP/HTTPS proxy to the appliance IP and listen port (for example
10.0.0.5:8080). - Browse to a simple HTTP site (or HTTPS if your clients already trust the appliance for inspection — skip HTTPS Inspection for day one if unsure).
- Open Reports → Detailed logs. You should see your request with username (or anonymous), URL, and status.
5. Add a simple Access Profiles rule
Access restrictions decides who may use SafeSquid. Access Profiles decides what those users may fetch (categories, sites, profiles).- Open Access Profiles → Default Policies (or Secondary Policies).
- Add a DENY rule for a category you can test safely (or a specific host if categories are not ready yet).
6. When something fails
- Note the time, client IP, and URL.
- Search Reports → Detailed logs for
filter_nameandfiltering_reason. - On a test network only, set System configuration → Send Debugging Headers To → CLIENT and inspect response headers in the browser. See Debug response headers.
- Turn debugging headers back to NONE when finished.
What to do next
- Authentication — Kerberos / SSO or System authentication so logs show real usernames
- Integrate LDAP — groups for policy
- HTTPS Inspection — decrypt HTTPS when your policy requires it (plan client trust carefully)
- SSqore and Categorize Web-Sites — category-based Access Profiles
- Application Signatures — tag client applications for policy
- SqScan or Clam antivirus — malware scanning
- Subscription — license and feed updates
- Architecture — how sections fit together