# WebPageTest Private - 'no successful results'

> A potential quick fix for "The test completed but there were no successful results." in WebPageTest private instances.

Author: Simon Hearne (https://simonhearne.com/about/)
Published: 2019-08-09
Canonical: https://simonhearne.com/2019/wpt-private-no-successful-results/
Tags: WebPerf, webpagetest

---
I recently configured a new [private WebPageTest instance](https://github.com/WPO-Foundation/webpagetest-docs/blob/master/user/Private%20Instances/README.md) on AWS to use SSL provided by [Let's Encrypt](https://letsencrypt.org/), using EFF's awesome [CertBot](https://certbot.eff.org/).

When running my first set of tests I noticed big delays (multiple minutes per test) and when the tests finally completed they all reported `The test completed but there were no successful results.`.

A quick look at the access log showed that the agents were getting jobs, but not submitting the results back to the server. I saw a bunch of `HTTP 301` responses to the workdone POSTs:

`POST /work/workdone.php?run=1... HTTP/1.1" 301 178 "-" "python-requests/2.22.0"`

Seeing the `301` responses (and no subsequent `200`s) made me realise that CertBot had added a default redirect from port 80 to port 443 to my nginx config (found at `/etc/nginx/sites-enabled/default` for the WebPageTest AMI).

```js
server {
    if ($host = private.wpt.host) {
        return 301 https://$host$request_uri;
    } # managed by Certbot
       listen 80;
       server_name private.wpt.host;
    return 404; # managed by Certbot
}
```

Simply commenting out this `server` block to remove the redirect and bouncing the nginx server immediately resolved the issue. CertBot does ask if it should add the redirect, so simply saying no during configuration would have solved the issue! It would be trivial to allow test agents to communicate on :80 based on the workdone path to get the best of both worlds.

If that is not the cause of your issue, it may be caused by the use of 64-bit windows clients which cannot do traffic shaping using dummynet. Simply adding `connectivity=LAN` to `locations.ini` for the test locations should resolve the issue.

