{"id":310,"date":"2026-10-13T12:31:15","date_gmt":"2026-10-13T12:31:15","guid":{"rendered":"http:\/\/www.scmgalaxy.com\/tutorials\/2012\/02\/13\/perforce-network-troubleshooting-hints\/"},"modified":"2026-10-13T12:31:15","modified_gmt":"2026-10-13T12:31:15","slug":"perforce-network-troubleshooting-hints","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/perforce-network-troubleshooting-hints\/","title":{"rendered":"Perforce Network Troubleshooting: A Practical Workflow for Port, DNS, and Firewall Issues"},"content":{"rendered":"\n

Originally published on 2012-02-13; fully revised and updated.<\/em><\/p>\n\n\n\n

If Perforce clients cannot connect (or connectivity is intermittent), you need to isolate whether the problem is on the server, the network path, name resolution, or endpoint policy. This runbook is for administrators and DevOps engineers who want a fast, repeatable troubleshooting sequence using core commands available on Windows, Linux, and macOS.<\/p>\n\n\n\n

\"Perforce<\/figure>\n\n\n\n

Quick troubleshooting workflow<\/h2>\n\n\n\n

Follow this order so you do not spend time on DNS or routing before confirming that the Perforce server is actually listening and accepting local connections.<\/p>\n\n\n\n

\nflowchart TD\n    A[Client cannot connect to Perforce] --> B[On server: check port 1666 is listening]\n    B --> C{Listening on expected port}\n    C -- no --> D[Start or reconfigure p4d and P4PORT]\n    C -- yes --> E[Test local connection with p4 info]\n    E --> F{Local test succeeds}\n    F -- no --> D\n    F -- yes --> G[From client: ping and TCP port test]\n    G --> H{TCP port reachable}\n    H -- no --> I[Check firewall and network path]\n    H -- yes --> J[Check DNS resolution]\n    J --> K{Hostname and IP both work}\n    K -- no --> L[Fix DNS or host entry]\n    K -- yes --> M[Investigate intermittent latency or packet loss]\n<\/pre>\n\n\n\n
Step-by-step checks from host to network<\/h2>\n\n\n\n
1) Confirm the Perforce server is listening on the expected port<\/h3>\n\n\n\n
The original guidance checks for a listening socket on port 1666 (default in many deployments). If nothing is listening, clients cannot connect regardless of DNS or firewall state.<\/p>\n\n\n
# Linux\/macOS<\/span>\nnetstat -an | grep 1666<\/span>\nss -lntp | grep 1666<\/span>\n\n# Windows (Command Prompt)<\/span>\nnetstat -a | findstr 1666<\/span><\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
Look for a LISTEN<\/strong> state on the Perforce port you expect.<\/p>\n\n\n\n
2) Verify local loopback connectivity from the server itself<\/h3>\n\n\n\n
This separates server process issues from network path issues.<\/p>\n\n\n
p4<\/span> -p<\/span> 127.0<\/span>.0<\/span>.1<\/span>:1666<\/span> info<\/span><\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
If this fails on the server host, focus on the Perforce service and configuration before testing external clients.<\/p>\n\n\n\n
3) Validate P4PORT configuration<\/h3>\n\n\n\n
The original post notes that setting P4PORT<\/code> to localhost:1666<\/code> restricts access to local-only connections. Using 1666<\/code> makes the service listen on all interfaces.<\/p>\n\n\n
# Windows service context (as shown in the original guidance)<\/span>\np4 set -S Perforce P4PORT\np4 set -S Perforce P4PORT=1666<\/span>\n\n# Linux\/macOS examples<\/span>\nexport P4PORT=1666<\/span>\np4d -r \"$P4ROOT\"<\/span> -p 1666<\/span> [other flags]<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
4) Test client reachability (ICMP and TCP)<\/h3>\n\n\n\n
First verify basic network reachability, then verify the actual Perforce TCP port.<\/p>\n\n\n
# From a client host<\/span>\nping perforce-server\n\n# TCP test<\/span>\ntelnet perforce-server 1666<\/span>\n# or, if telnet is unavailable:<\/span>\nnc -vz perforce-server 1666<\/span><\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
If ping fails, ICMP may be blocked or routing is broken. If ping works but TCP fails, investigate firewalls, port filters, security groups, or host-based ACLs.<\/p>\n\n\n\n
5) Check firewall and port filtering policy<\/h3>\n\n\n\n
Ensure inbound TCP traffic to the Perforce port is allowed on the server side, and that outbound\/return traffic is not blocked.<\/p>\n\n\n\n